Summary
GBL_MEM_UTIL does not accurately represent true memory utilization on Linux servers
Question
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:
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
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.