Details

      Description

      proc.num show incorrect data under FreeBSD. Example:

      ps ax|wc -l
      59

      zabbix_agentd -t proc.num[]
      proc.num[] [u|127]

      1. proc.c.patch
        1.0 kB
        Jim Riggs
      2. proc.c+vsz.patch
        2 kB
        Jim Riggs

        Issue Links

          Activity

          Hide
          Oleksiy Zagorskyi added a comment -

          Several users can confirm the same: http://www.zabbix.com/forum/showthread.php?t=22322
          I'm too.

          Show
          Oleksiy Zagorskyi added a comment - Several users can confirm the same: http://www.zabbix.com/forum/showthread.php?t=22322 I'm too.
          Hide
          Alexander Vladishev added a comment -

          Confirmed in version pre1.8.6, r20279.

          Show
          Alexander Vladishev added a comment - Confirmed in version pre1.8.6, r20279.
          Hide
          Ya Bo added a comment -

          FreeBSD 9.0, zabbix-agent-1.8.10,2

          zabbix-1.8.10/src/libs/zbxsysinfo/freebsd/proc.c
          #if(__FreeBSD_version > 500000)
          if (proc[i].ki_flag & P_KTHREAD) /* skip a system thread */
          continue;
          #endif

          не работает, в результате имеем +системные треды

          Show
          Ya Bo added a comment - FreeBSD 9.0, zabbix-agent-1.8.10,2 zabbix-1.8.10/src/libs/zbxsysinfo/freebsd/proc.c #if(__FreeBSD_version > 500000) if (proc [i] .ki_flag & P_KTHREAD) /* skip a system thread */ continue; #endif не работает, в результате имеем +системные треды
          Hide
          Oleksiy Zagorskyi added a comment -

          related issue ZBX-4704

          Show
          Oleksiy Zagorskyi added a comment - related issue ZBX-4704
          Hide
          Jim Riggs added a comment -

          Please try the attached patch. It correctly calls sysctl() for proc.num and proc.mem with KERN_PROC_PROC instead of KERN_PROC_ALL for FreeBSD 5 and later. (Is this check really necessary anymore? Is < v5 supported?)

          This has fixed the issue in my environment.

          Show
          Jim Riggs added a comment - Please try the attached patch. It correctly calls sysctl() for proc.num and proc.mem with KERN_PROC_PROC instead of KERN_PROC_ALL for FreeBSD 5 and later. (Is this check really necessary anymore? Is < v5 supported?) This has fixed the issue in my environment.
          Hide
          Ya Bo added a comment - - edited

          FreeBSD 8.3-PRERELEASE
          zabbix-agent-1.8.10_1,2

          confirm, patch is good

          Show
          Ya Bo added a comment - - edited FreeBSD 8.3-PRERELEASE zabbix-agent-1.8.10_1,2 confirm, patch is good
          Hide
          Pavel Timofeev added a comment -

          thanks to Jim! proc.num work on FreeBSD 9.0-RELEASE amd64.

          But I can't decide about proc.mem. Which unit does proc.mem return? Kbytes, bytes, etc.? Documentation didn't help=(

          Show
          Pavel Timofeev added a comment - thanks to Jim! proc.num work on FreeBSD 9.0-RELEASE amd64. But I can't decide about proc.mem. Which unit does proc.mem return? Kbytes, bytes, etc.? Documentation didn't help=(
          Hide
          richlv added a comment -

          regarding documentation, could you please open another issue (documentation component) ?
          thanks

          Show
          richlv added a comment - regarding documentation, could you please open another issue (documentation component) ? thanks
          Hide
          Pavel Timofeev added a comment -
          Show
          Pavel Timofeev added a comment - 2 richlv: https://support.zabbix.com/browse/ZBX-4831
          Hide
          Pavel Timofeev added a comment -

          Jim, does proc.mem work for you?

          Show
          Pavel Timofeev added a comment - Jim, does proc.mem work for you?
          Hide
          Pavel Timofeev added a comment -

          Jim's patch applied
          [root@octans ]# ps -axo vsz,rss,command | grep syslogd
          12184 1340 /usr/sbin/syslogd -s
          [root@octans ]# zabbix_get -s octans -I 192.168.2.6 -k 'proc.mem[syslogd]'
          2232320

          2232320 Bytes = 2180 KBytes but != 12184 KBytes or 1340 KBytes returned by ps

          Show
          Pavel Timofeev added a comment - Jim's patch applied [root@octans ] # ps -axo vsz,rss,command | grep syslogd 12184 1340 /usr/sbin/syslogd -s [root@octans ] # zabbix_get -s octans -I 192.168.2.6 -k 'proc.mem [syslogd] ' 2232320 2232320 Bytes = 2180 KBytes but != 12184 KBytes or 1340 KBytes returned by ps
          Hide
          Jim Riggs added a comment -

          The "memory usage" of a process is a controversial and subjective topic. There are many different views about what actually constitutes a proc's memory usage.

          Currently, the zabbix code is using text size + data size + stack size for proc.mem (ki_tsize + ki_dsize + ki_ssize), whereas `top' and `ps' display resident size (ki_rssize) and VM size (ki_size). This is why the values from zabbix vs. top and ps are different. I would think that to eliminate confusion and to make the zabbix value more "verifiable," we should probably switch to using ki_rssize.

          Thoughts? What are other OSes doing? I haven't dug into the linux code, for example.

          Show
          Jim Riggs added a comment - The "memory usage" of a process is a controversial and subjective topic. There are many different views about what actually constitutes a proc's memory usage. Currently, the zabbix code is using text size + data size + stack size for proc.mem (ki_tsize + ki_dsize + ki_ssize), whereas `top' and `ps' display resident size (ki_rssize) and VM size (ki_size). This is why the values from zabbix vs. top and ps are different. I would think that to eliminate confusion and to make the zabbix value more "verifiable," we should probably switch to using ki_rssize. Thoughts? What are other OSes doing? I haven't dug into the linux code, for example.
          Hide
          richlv added a comment -

          i suppose we will want to match some value(s) from standard tools like ps if only to reduce the confusion - as noted, there is no definite "used memory" value, it's all quite relative.

          Show
          richlv added a comment - i suppose we will want to match some value(s) from standard tools like ps if only to reduce the confusion - as noted, there is no definite "used memory" value, it's all quite relative.
          Hide
          Jim Riggs added a comment -

          Attached is proc.c+rss.patch which includes the original patch plus a switch to using the resident size for proc.mem as discussed. This works for me in FreeBSD 8 and 9 for single and multiple processes.

          It would be nice to get these issues fixed sooner rather than later, if possible. The proc.num issue, specifically, has been causing problems for quite some time.

          Show
          Jim Riggs added a comment - Attached is proc.c+rss.patch which includes the original patch plus a switch to using the resident size for proc.mem as discussed. This works for me in FreeBSD 8 and 9 for single and multiple processes. It would be nice to get these issues fixed sooner rather than later, if possible. The proc.num issue, specifically, has been causing problems for quite some time.
          Hide
          Jim Riggs added a comment -

          I guess the question still remains, is resident size what people expect from proc.mem or VM size? Resident is closer to what the value was before, but VM size might give a better picture of actual memory footprint.

          Hrm. Looking at the Linux agent, it is pulling the VM size (vsz). We should probably match. New patch coming...

          Show
          Jim Riggs added a comment - I guess the question still remains, is resident size what people expect from proc.mem or VM size? Resident is closer to what the value was before, but VM size might give a better picture of actual memory footprint. Hrm. Looking at the Linux agent, it is pulling the VM size (vsz). We should probably match. New patch coming...
          Hide
          Jim Riggs added a comment -

          OK, proc.c+vsz.patch should be good to go. Original patch to fix proc.num + vsize patch to "fix" proc.mem on FreeBSD. Tested on FreeBSD 8 and 9.

          Show
          Jim Riggs added a comment - OK, proc.c+vsz.patch should be good to go. Original patch to fix proc.num + vsize patch to "fix" proc.mem on FreeBSD. Tested on FreeBSD 8 and 9.
          Hide
          Oleksiy Zagorskyi added a comment -

          Jim, I'm sorry, it's not related to proc.mem, but do you know about changes for agent 2.0 ?
          http://blog.zabbix.com/when-alexei-isnt-looking/#vm.memory.size implemented here: ZBXNEXT-1024
          Would be good to follow latest ideology

          I think would be better to not mix here discussion about proc.num and proc.mem

          Also see ZBXNEXT-1078 and ZBX-4532

          Show
          Oleksiy Zagorskyi added a comment - Jim, I'm sorry, it's not related to proc.mem, but do you know about changes for agent 2.0 ? http://blog.zabbix.com/when-alexei-isnt-looking/#vm.memory.size implemented here: ZBXNEXT-1024 Would be good to follow latest ideology I think would be better to not mix here discussion about proc.num and proc.mem Also see ZBXNEXT-1078 and ZBX-4532
          Hide
          Pavel Timofeev added a comment -

          Oleksiy Zagorskyi, ZBXNEXT-1024 is not relative feature/fix. ZBXNEXT-1024 is on a different plane.

          Show
          Pavel Timofeev added a comment - Oleksiy Zagorskyi, ZBXNEXT-1024 is not relative feature/fix. ZBXNEXT-1024 is on a different plane.
          Hide
          Pavel Timofeev added a comment -

          > Jim Riggs added a comment - 2012 Apr 26 07:07
          > OK, proc.c+vsz.patch should be good to go. Original patch to fix proc.num + vsize patch to "fix" proc.mem on FreeBSD. Tested on FreeBSD 8 and 9.

          Excellent, Jim! Patch works fine on FreeBSD 9-RELEASE amd64. I hope this patch will be included in the nearest release.

          Show
          Pavel Timofeev added a comment - > Jim Riggs added a comment - 2012 Apr 26 07:07 > OK, proc.c+vsz.patch should be good to go. Original patch to fix proc.num + vsize patch to "fix" proc.mem on FreeBSD. Tested on FreeBSD 8 and 9. Excellent, Jim! Patch works fine on FreeBSD 9-RELEASE amd64. I hope this patch will be included in the nearest release.
          Hide
          Alexander Vladishev added a comment -

          Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-3897

          Fixed incorrect processing of proc.num[] item.
          proc.mem[] item will be fixed later under ZBXNEXT-1078 or ZBX-4532.

          Show
          Alexander Vladishev added a comment - Fixed in the development branch svn://svn.zabbix.com/branches/dev/ZBX-3897 Fixed incorrect processing of proc.num[] item. proc.mem[] item will be fixed later under ZBXNEXT-1078 or ZBX-4532 .
          Hide
          dimir added a comment -

          I wonder why do I get less processes with zabbix get on FreeBSD 7.3. I tried 1.8.5, latest 1.8 with and without the fix:

          $ uname -a
          FreeBSD freebsd73.zabbix.com 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Sun Mar 21 06:15:01 UTC 2010 root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

          $ ps ax|wc -l
          81

          $ bin/zabbix_get -s 127.0.0.1 -k agent.version
          1.8.5
          $ bin/zabbix_get -s 127.0.0.1 -k proc.num[]
          39

          $ bin/zabbix_get -s 127.0.0.1 -k agent.version
          1.8.13rc1

          1. without the fix
            $ bin/zabbix_get -s 127.0.0.1 -k proc.num[]
            39
          2. with the fix
            $ bin/zabbix_get -s 127.0.0.1 -k proc.num[]
            39
          Show
          dimir added a comment - I wonder why do I get less processes with zabbix get on FreeBSD 7.3. I tried 1.8.5, latest 1.8 with and without the fix: $ uname -a FreeBSD freebsd73.zabbix.com 7.3-RELEASE FreeBSD 7.3-RELEASE #0: Sun Mar 21 06:15:01 UTC 2010 root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 $ ps ax|wc -l 81 $ bin/zabbix_get -s 127.0.0.1 -k agent.version 1.8.5 $ bin/zabbix_get -s 127.0.0.1 -k proc.num[] 39 $ bin/zabbix_get -s 127.0.0.1 -k agent.version 1.8.13rc1 without the fix $ bin/zabbix_get -s 127.0.0.1 -k proc.num[] 39 with the fix $ bin/zabbix_get -s 127.0.0.1 -k proc.num[] 39
          Hide
          dimir added a comment -

          It appeared to be a problem on my side, please ignore the comment above.

          Show
          dimir added a comment - It appeared to be a problem on my side, please ignore the comment above.
          Hide
          dimir added a comment -

          Successfully tested, now the number of processes is reported properly.

          Show
          dimir added a comment - Successfully tested, now the number of processes is reported properly.
          Hide
          Alexander Vladishev added a comment - - edited

          Fixed in versions pre-1.8.14 r27534, pre-2.0.1 r27689, pre-2.1.0 (beta) r27694

          Show
          Alexander Vladishev added a comment - - edited Fixed in versions pre-1.8.14 r27534, pre-2.0.1 r27689, pre-2.1.0 (beta) r27694

            People

            • Assignee:
              Unassigned
              Reporter:
              gescheit
            • Votes:
              4 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: