LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (http://www.linuxquestions.org/questions/linux-general-1/)
-   -   (Large) Memory usage discrepancy between top and gnome-system-monitor (http://www.linuxquestions.org/questions/linux-general-1/large-memory-usage-discrepancy-between-top-and-gnome-system-monitor-928561/)

dahc 02-09-2012 07:48 PM

(Large) Memory usage discrepancy between top and gnome-system-monitor
 
[I found an old thread relating to this, but the only reply was a dead article link, along with some silly threads where the distinction between GiB and GB was apparently misunderstood.]

I've noticed this on a several machines and a few different distributions of GNU/Linux (including Fedora and Ubuntu): The used memory reported by top (or 'free -m' -- they always agree) is significantly higher than that reported by gnome-system-monitor. For example, on the Fedora 16 system from which I'm typing this, top reports...

Code:

top - 18:07:28 up 17 days, 14:25,  3 users,  load average: 0.36, 0.31, 0.30
Tasks: 188 total,  3 running, 185 sleeping,  0 stopped,  0 zombie
Cpu(s):  6.9%us,  1.6%sy,  0.0%ni, 91.2%id,  0.0%wa,  0.2%hi,  0.1%si,  0.0%st
Mem:  12049356k total,  8791056k used,  3258300k free,  432116k buffers
Swap: 14155772k total,    23208k used, 14132564k free,  6268156k cached

...meanwhile gnome-system-monitor says "Memory: 2.0 GiB (17.4 %) of 11.5 GiB".

The gui's report makes much more sense given the load on the system (just a bunch of firefox tabs, a couple terminals, and gnome-system-monitor itself running on Gnome 3).

My suspicion (perhaps having spent a bit too much time coding in C lately) is that top is only aware of memory usage from the perspective of the kernel -- from which glibc's malloc() implementation checks out large blocks via calls to sbrk() or whatever and then doesn't return that memory to the kernel when it's freed, opting instead to keep it around for future calls to malloc() (since sbrk() calls are relatively expensive). If gnome-system-monitor is aware of all available memory, including the memory that's been freed but not returned to the kernel, that's really cool. I'd love to know how to get at that information in a terminal. After all, isn't that what one should actually be interested in from an administrative point of view?

Stepping back a bit, the effect is so dramatic that I'd be surprised if it were actually to do with malloc(), but Linux surprises me (usually pleasantly) all the time. Anyway if someone who knows what's really going on here could set me straight or confirm my suspicions, I'd really appreciate it.

dahc

syg00 02-09-2012 10:03 PM

This is such an old chestnut. Apples and Oranges.
Have a look at the second line of the "free" output - that is the "total" minus {page}cache usage. See how that compares to the GUI.

dahc 02-09-2012 10:58 PM

HAH, thanks for the palm-to-face realization. 'Tis the problem with learning in relative isolation -- sometimes I need somebody to point out the obvious.


All times are GMT -5. The time now is 03:03 AM.