GBL_MEM_UTIL does not match with other OS tools on Linux

Document ID:KM1401642
Creation Date:06-Jun-2012
Modified Date:06-Jun-2012
- Micro Focus Products:
  performance agent

Summary

GBL_MEM_UTIL does not accurately represent true memory utilization on Linux servers

Question

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

Answer

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:

GBL_MEM_SYS_UTIL
GBL_MEM_CACHE_UTIL
GBL_MEM_USER_UTIL

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.