[ZBX-9734] Wrong memory Freebsd 10.1 Created: 2015 Jul 28 Updated: 2017 May 30 Resolved: 2015 Aug 19 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Agent (G) |
Affects Version/s: | 2.4.5 |
Fix Version/s: | None |
Type: | Incident report | Priority: | Critical |
Reporter: | sysops | Assignee: | Unassigned |
Resolution: | Won't fix | Votes: | 0 |
Labels: | freebsd, memory | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
freebsd 10.1 |
Description |
Agent report errata:
example in Oracle Linux (RHEL7)
|
Comments |
Comment by Aleksandrs Saveljevs [ 2015 Jul 28 ] |
The issue description does not say what the problem is, but you probably mean that according to "proc.mem[,zabbix]", the agent uses a little memory on FreeBSD and a lot of memory on Linux. By itself, this is no indication of a bug: different methods are used on these operating systems for determining process memory usage and "proc.mem[,zabbix]" is generally not the best way of measuring memory usage for multi-process processes with shared memory, because a lot of common memory will be counted multiple times (at least on Linux). If you wish this issue to be considered for investigation, you should provide a description of the problem and what the expected output should be. |
Comment by sysops [ 2015 Jul 28 ] |
Sorry for short description. $ zabbix_get -s 192.168.77.105 -k 'proc.mem[,zabbix]' 2506752 Another example: $ zabbix_get -s 192.168.77.105 -k 'proc.mem[,mysql]' 13647872 So proc.mem on a FreeBSD system report an errata value of consumed RAM for ON FREEBSD 10.1 #top | grep zabbix 1280 zabbix 1 4 0 25512K 3104K select 1 0:07 0.00% zabbix_agentd 1281 zabbix 1 4 0 25512K 3096K select 1 0:07 0.00% zabbix_agentd 1279 zabbix 1 23 0 25512K 3096K select 1 0:07 0.00% zabbix_agentd 1278 zabbix 1 20 0 25512K 2944K nanslp 0 0:03 0.00% zabbix_agentd 1282 zabbix 1 20 0 25460K 2840K nanslp 0 0:02 0.00% zabbix_agentd #ps aux | grep zabbix zabbix 1277 0.0 0.0 25460 2716 - I 11:11PM 0:00.00 /usr/local/sbin/zabbix_agentd zabbix 1278 0.0 0.0 25512 2944 - S 11:11PM 0:02.73 zabbix_agentd: collector [idle 1 sec] (zabbix_agentd) zabbix 1279 0.0 0.0 25512 3096 - S 11:11PM 0:07.21 zabbix_agentd: listener #1 [waiting for connection] (zabbix_agentd) zabbix 1280 0.0 0.0 25512 3104 - S 11:11PM 0:07.31 zabbix_agentd: listener #2 [waiting for connection] (zabbix_agentd) zabbix 1281 0.0 0.0 25512 3096 - S 11:11PM 0:07.24 zabbix_agentd: listener #3 [waiting for connection] (zabbix_agentd) zabbix 1282 0.0 0.0 25460 2840 - S 11:11PM 0:01.56 zabbix_agentd: active checks #1 [idle 1 sec] (zabbix_agentd) #top | grep mysql 35461 mysql 55 20 0 711M 610M uwait 0 0:54 0.00% mysqld #ps aux | grep mysql USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND mysql 35461 0.0 7.5 727564 624552 - I 7:40AM 0:55.70 /usr/local/libexec/mysqld mysql 35269 0.0 0.0 17064 2640 - Is 7:40AM 0:00.01 /bin/sh /usr/local/bin/mysqld_safe |
Comment by Aleksandrs Saveljevs [ 2015 Jul 28 ] |
Thank you for an elaborate explanation! |
Comment by Glebs Ivanovskis (Inactive) [ 2015 Aug 18 ] |
Time has come for elaborate explanation from our side! The problem is more likely to be in the lack of documentation but not in the proc.mem[] item itself. The reason for such huge difference in proc.mem[] output on Linux and FreeBSD is that on the former zabbix agent returns virtual memory size but on the latter it outputs size taken by process code, data and stack. (Call #ps -o tsiz -o dsiz -o ssiz and add up columns to get the same result as zabbix agent.) I don't think it would be a good idea to change behaviour of proc.mem[] on FreeBSD to make it return virtual memory size because it would affect existing installations. Current trunk already has proc.mem[] with broadened functionality (https://support.zabbix.com/browse/ZBXNEXT-1078). There is one more parameter and one can use proc.mem[,,,,vsize] and proc.mem[,,,,rss] to see virtual memory size and resident set size. More information on this can be found here:
|