Detective wrong active memory FreeBSD 9.2-STABLE

Issue #30 resolved
Former user created an issue

Hi!

I have a problem for detective real memory:

$ top

last pid: 73443;  load averages:  0.08,  0.09,  0.13                                                                                                        up 15+03:41:50  14:45:26
42 processes:  1 running, 41 sleeping
CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
Mem: 424M Active, 2418M Inact, 3672M Free
Swap: 8192M Total, 3620K Used, 8188M Free

$ monit status

System 'servername'
  status                            Running
  monitoring status                 Monitored
  load average                      [0.10] [0.09] [0.13]
  cpu                               4.9%us 1.6%sy
  memory usage                      10121088 kB [241.3%]
  swap usage                        3620 kB [0.0%]
  data collected                    Tue, 15 Apr 2014 14:46:48

Comments (15)

  1. Mike

    Absolutely right, i have the same problem

    $ monit -V

    This is Monit version 5.8
    Copyright (C) 2001-2014 Tildeslash Ltd. All Rights Reserved.
    
  2. Tildeslash repo owner

    Hello,

    i'm unable to reproduce the problem.

    Few questions:

    1.) which Monit version it is? (Michael reported 5.8)

    2.) did the problem started after some Monit upgrade or was it always like this?

    3.) do you use the pre-compiled binaries or did you compile Monit from the source code? (either manually or using Monit port). If pre-compiled, please verify that you're running the same Monit binary architecture as you r system - for example x64 on 64-bit system ... if you're running x86 (32-bit) on 64-bit, it may not be able to read the data correctly via system API.

    4.) is Monit running in FreeBSD jail or is it real system?

    Regards, The Monit team

  3. Mike

    Hi, In my case that:

    1. This is Monit version 5.8 x64 - i've download
    2. I've compile from source code because current port version is 5.6
    3. FreeBSD x64 running on VDS

    Best regards

  4. Tildeslash repo owner

    What type of VDS it is, Michael?

    The problem is most probably related to virtual environment - if the environments are not fully separated, the virtualization framework usually mangles the data presented to the virtual host. In this case it seems that Monit reads the memory usage of the whole machine, not just the virtual host where it is running.

  5. Mike

    Okay, but why other sysutils detect memory absolutely right? ex: top, htop, etc.? Can you give me advice how i can fix that problem?

  6. Mike

    For example, this script show me next view:

    free
    System memory information (page size is 4096 bytes)
    WE ARE IN THE JAIL
    mem_wire:                 0 (      0MB) Wired: disabled for paging out
    mem_active:       415965184 (    396MB) Active: recently referenced
    mem_inactive:    2458198016 (   2344MB) Inactive: recently not referenced
    mem_cache:                0 (      0MB) Cached: almost avail. for allocation
    mem_free:        3879002112 (   3699MB) Free: fully available for allocation
    -------------- ------------ -----------
    mem_phys:        4294967296 (   4096MB) Total real memory available
    

    and 396MB of active used memory is right

  7. Tildeslash repo owner

    Hello Micheal,

    we have tried to replicate the issue - no luck (tested on FreeBSD9.2-p4 and FreeBSD9.2-p5), memory statistics worked normally both inside and outside the jail.

    We were used vm.vmtotal stats to get active real memory usage - switched to vm.stats.vm.v_active_count now.

    Please can you download and compile the development Monit version from BitBucket and verify if the fix works on your system? (we have tested it on our machines already, but since we were not able to reproduce the problem, we can verify it will provide correct data on your system).

    You ca download the development version here: https://bitbucket.org/tildeslash/monit/get/master.tar.bz2

    To compile:

    sh ./bootstrap
    ./configure
    gmake
    

    Best regards, The Monit team

  8. Log in to comment