Ad Widget

Collapse

vm.memory.size reporting wrong

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • bmcclure
    Junior Member
    • Apr 2010
    • 14

    #1

    vm.memory.size reporting wrong

    I have four OpenVZ VPSes. Three of them run CentOS, the other runs Ubuntu.

    I have Zabbix Server and Agent 1.8.2 on the Ubuntu server, and Zabbix Agent 1.8.2 on the other three.

    All of the memory values being retrieved by Zabbix seem to make no sense.

    Server: centaurus
    Actual total: 2 GB
    Zabbix total: 7.79 GB
    Actual free: 963 MB
    Zabbix free: 708.71 MB

    Server: andromeda
    Actual total: 512 MB
    Zabbix total: 2 GB
    Actual free: 378 MB
    Zabbix free: 195.30 MB


    Is it somehow getting the values from the OpenVZ server and not from the actual VPS node the agent is running on? I'm not sure where it would get that value, but since the kernel is shared between the host and virtual servers, maybe that explains it.

    The question then is, how can I accurately monitor memory on the individual VPSes?
  • bmcclure
    Junior Member
    • Apr 2010
    • 14

    #2
    Nobody has had this issue?

    Is anyone using the vm.memory.size check on a VPS and getting correct values?

    I'd love to get to the bottom of this--memory usage is one of the top things I want to monitor.

    Comment

    • chriso
      Junior Member
      • May 2010
      • 20

      #3
      same..

      I have the same issue on solaris 10. The server has 16gb installed. A zabbix_get for vm.memory.size[total] returns 31 gig. I've also seen values from proc.mem[] that make no sense in terms of what prstat shows.

      Comment

      • bmcclure
        Junior Member
        • Apr 2010
        • 14

        #4
        In my case this was definitely related to OpenVZ and the fact that each VM shares a kernel and many low-level functions with the host server.

        All of the memory reporting tools need to be modified by OpenVZ to report correctly for the container they are in--if they are not modified, they will report the memory values for the host server.

        Zabbix uses some method which OpenVZ has not modified to work at the node-level. I just created an alternate memory script for Zabbix which parses the output of the 'free' command, and that works fine. You may wish to try that as well.

        I should add, I have since switched to Xen servers, and this issue disappeared completely-Xen acts more like a dedicated server and has its own dedicated memory.
        Last edited by bmcclure; 28-05-2010, 21:16.

        Comment

        • chriso
          Junior Member
          • May 2010
          • 20

          #5
          Originally posted by chriso
          I have the same issue on solaris 10. The server has 16gb installed. A zabbix_get for vm.memory.size[total] returns 31 gig. I've also seen values from proc.mem[] that make no sense in terms of what prstat shows.
          Please disregard my post. I was looking at wrong values.

          Comment

          • XKaliber
            Junior Member
            • Jun 2012
            • 8

            #6
            Originally posted by bmcclure
            In my case this was definitely related to OpenVZ and the fact that each VM shares a kernel and many low-level functions with the host server.

            All of the memory reporting tools need to be modified by OpenVZ to report correctly for the container they are in--if they are not modified, they will report the memory values for the host server.

            Zabbix uses some method which OpenVZ has not modified to work at the node-level. I just created an alternate memory script for Zabbix which parses the output of the 'free' command, and that works fine. You may wish to try that as well.

            I should add, I have since switched to Xen servers, and this issue disappeared completely-Xen acts more like a dedicated server and has its own dedicated memory.
            Can you please post the script you used and the method to implement for the zabbix agent? Thank you!

            Comment

            Working...