It's suggested to change VmSize to the ... hmm ... seems ... VmRSS memory.
VmRSS will be better because VmSize is almost meaningless.
In the sources ./src/libs/zbxsysinfo/linux/proc.c#266 we can see that namely VIRT is calculated:
if (0 != strncmp(tmp, "VmSize:\t", 8))
Note in the "top" command VmRSS is a RSS column and VmSize is a VIRT column.
See examples:
nscd:
- egrep 'VmSize|VmRSS' /proc/`pidof nscd`/status
VmSize: 225328 kB
VmRSS: 2904 kB
synergy:
- egrep 'VmSize|VmRSS' /proc/`pidof synergys`/status
VmSize: 286688 kB
VmRSS: 38888 kB
automount:
- egrep 'VmSize|VmRSS' /proc/`pidof automount`/status
VmSize: 314872 kB
VmRSS: 4908 kB
See second example - attached "oleksiy's_top.png"
We are trying to monitor a memory consumed by zabbix_server daemon.
1st stage )
"zabbix_server18node1" is a daemon started with big caches in configuration:
CacheSize=1G
TrendCacheSize=256M
HistoryCacheSize=1G
HistoryTextCacheSize=256M
"zabbix_server18" is a daemon started with the default configuration.
2nd stage)
only "zabbix_server18" daemon running with the default configuration.
As you see amount of used memory for whole OS almost not changed for first and second stage.
According to the # man top:
VIRT – Virtual Image (kb)
The total amount of virtual memory used by the task. It includes all code, data and shared libraries plus pages that have been swapped out and pages that have been mapped but not used.
RES – Resident size (kb)
The non-swapped physical memory a task has used.
These values according to the # man ps:
VSZ virtual memory size of the process in KiB (1024-byte units). Device mappings are currently excluded; this is subject to change. (alias vsize).
RSS resident set size, the non-swapped physical memory that a task has used (in kiloBytes). (alias rssize, rsz).
Values for my configuration:
- zabbix_get -s localhost -k 'proc.mem[,,,zabbix18]'
4259160064 - zabbix_get -s localhost -k 'proc.mem[,,,18node1]'
78514339840
Calculation for "zabbix_server18node1" daemon: 28 process (default configuration) * 2.6G (VIRT per process) = ~73GB which ~ equals received 78514339840
So the key "proc.mem[]" calculates virtual memory (VIRT) which seems is not the same as "memory used" according to documentation.
That is why it should be reconsidered.
- duplicates
-
ZBXNEXT-1078 add fifth parameter to the key "proc.mem" - <type of memory>
- Closed