[SGVLUG] Memory consumption monitoring?
Emerson, Tom
Tom.Emerson at wbconsultant.com
Fri Apr 28 16:50:24 PDT 2006
> -----Original Message----- Of Sean O'Donnell
>
> I'm confused a bit because comparing '/proc/meminfo' results
> w/ 'top', and the results displayed by 'gkrellm', are all different.
>
> ---
>
> $ cat /proc/meminfo
> total: used: free: shared: buffers: cached:
> Mem: 260747264 257048576 3698688 0 6164480 102109184
> $ top
> Mem: 254636k total, 251224k used, 3412k free
[converting "k" bytes to actual bytes, the "free" space difference is
about 204800 bytes]
> or is it that 'top' uses more memory than '/proc/meminfo',
> and that is actually accurate??
Actually, the way to state this is that "top uses more memory than cat"
-- as I'm sure you're well aware, the "/proc" hierarchy isn't a real
directory, and the files are generated "on the fly" by the kernel based
on what information they portray. Programs (or "processes") that want
to make use of this information then read and process the appropriate
file. So, with that in mind...
* When you use the "cat" program to display the contents, you're
launching a process to read the file /proc/meminfo
* When you use "top", you're launching a process that reads the file
/proc/meminfo, reads several other related files for various processes,
maintains a table of of those processes, displays the results (with some
cross tabulations), and pauses for a few seconds before doing this all
over again
In short, yes, top uses more memory than cat :)
Also:
* the "cat" program itself is fairly small
* the "top" program is over 5 times it's size -- on my system:
tom at osnut:~> ls -l `which cat`
-rwxr-xr-x 1 root root 15224 2003-09-23 10:51 /bin/cat
tom at osnut:~> ls -l `which top`
-r-xr-xr-x 1 root root 81100 2003-09-23 10:03 /usr/bin/top
So, at least 60k of that 200k is taken up by the program itself --
however running two ssh/xterm windows side-by-side with an instance of
"top" in each showed the same memory usage in both, but when I quit one
instance, the other instance's free space allocation changed by 20+ k (I
suspect there is/was sharing of code segments involved here...) Killing
the second instance showed an 80k difference:
["top" is running in a second window]
tom at osnut:~> free
total used free shared buffers
cached
Mem: 514120 488392 25728 0 81388
72724
[this number (25728) remained stable for several repetitions]
[quit "top" in the other window]
tom at osnut:~> free
total used free shared buffers
cached
Mem: 514120 488308 25812 0 81388
72724
A difference of 84k
BTW:
tom at osnut:~> cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 526458880 500027392 26431488 0 83341312 74469376
^^^^^^^^
988/COREDEV/TEMPTE%calc 25812 * 1024
26431488, $1935000, %144650000, #403/#20480, "..P."
^^^^^^^^
We have correlation! (so "free" is essentialy just as light-weight as
"cat")
Remember also that "some other process" [at/cron, or just some daemonic
posession] might kick in during your readings, so take multiple readings
to ensure quiescence...
More information about the SGVLUG
mailing list