GBL_MEM_UTIL does not match with other OS tools on Linux

  • KM1401642
  • 06-Jun-2012
  • 06-Jun-2012


GBL_MEM_UTIL does not accurately represent true memory utilization on Linux servers


GBL_MEM_UTIL does not match with other OS tools on Linux


For example:

The Linux utility "free" reports:


     total used free shared buffers cached

Mem:  3820 3697  123   0     613     1287


And the formula for memory util would be:

(Mem: used / Mem:total) * 100

(3697/3820)*100= 96,78


OVPA reports:


image text


Memory % does not match with free, but if “memory %” is added to “file cache %” the result is: 96, 97 which is a good match.
The root cause of the difference is that OVPA GBL_MEM_UTIL metric does not take into account file cache memory utilization. OVPA GBL_MEM_UTIL metric by default only takes into account the following metrics:
Many system administrators (specially those running Oracle) think that the memory utilization metric should also include GBL_MEM_FILE_PAGE_CACHE_UTIL. So the solution for this scenario, is to upgrade to Operations Agent 11 (OA 11) plus “OALIN_00003” patch.  OA 11 Patch 2 provides a new parm file option, “cachemem”, which enables the user to configure the agent to include the cache memory size while logging the total memory utilization for a node (value of the GBL_MEM_UTIL metric). This new parm file should be available in: /opt/perf/newconfig…
This is from the parm file:
# The following cachemem option determines how cache memory is bucketed.
# The value can be 'u' ('user') or 'f' ('free'). The default is 'free',
# to preserve compatibility with previous behavior. Until 2.6.18 kernels,
# the logical assignment of cache memory was free, as documented in many
# Linux blogs. Because at least some 2.6.18 kernels include shared memory
# segments as cache, it may make more sense to count cache as user
# memory, particularly on Oracle servers, which allocate large shared
# memory segments.
So OVPA users can replace the /var/opt/perf/parm file (save it somewhere else beforehand so that is is available as backup if needed) with the one in /opt/perf/newconfig and then configure it properly.  Alternatively, the relevant verbage from /opt/perf/newconfig/parm can be cut and pasted into the previously existing /var/opt/perf/parm file.  This second option would be especially useful if there are already a significant number of customizations (application definitions, thresholds, and other configurable options) in the current parm file.