l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
August 5: Social gathering
Next Installfest:
TBD
Latest News:
Jul. 4: July, August and September: Security, Photography and Programming for Kids
Page last updated:
2009 Aug 24 09:54

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] command to monitor memory usage
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] command to monitor memory usage



On Sun, 2009-08-23 at 10:27 -0700, Bill Kendrick wrote:
> On Sun, Aug 23, 2009 at 10:35:18AM -0500, Ken Bloom wrote:
> > AFAIK, because Linux has lots of great ways of sharing physical memory
> > pages between processes, and only loading the parts of libraries that it
> > needs, nothing can tell you how much physical memory space is occupied
> > by a given program.
> 
> Heh, so there are numerous different ways of not getting the precise answer.
> Awesome. ;)

Well, your response prompted me to do some more looking, and I
discovered smem (http://www.selenic.com/smem/) and /proc/self/smaps.


Consider the following:

[bloom@cat-in-the-hat ~]$ ps ux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...
bloom    11666  1.3  2.8 571668 113056 ?       Sl   13:20   0:23 /usr/lib/iceweasel/firefox-bin -a iceweasel
...

So it looks like FireFox is using 110 MB of RAM or so (including swap,
and including code that's never been loaded from disk).
But some of that RAM is used by other processes as well, like libc6
which practically every program on the whole system is using. Do we
really want to count all of libc6 against Firefox's memory usage?
Not really.

RSS in the above output stands for "resident set size". The linux
developers added a concept called PSS ("Proportional set size") which
measures each application's "fair share" of each shared area.

We can find out the PSS of a process from /proc/.../smaps.


[bloom@cat-in-the-hat ~]$ head /proc/11666/smaps
00400000-00408000 r-xp 00000000 08:01 2359370                            /usr/lib/xulrunner-1.9/xulrunner-stub
Size:                 32 kB
Rss:                  24 kB
Pss:                  24 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:        24 kB
Private_Dirty:         0 kB
Referenced:           24 kB
Swap:                  0 kB

This is very long, so I've only run head on it. It has about a dozen
lines of fields for each line in /proc/11666/maps, describing this kind
of information for each piece of memory that's mapped by the kernel.
(Remember that the heap and the stack show up in this list, so what that
really means is all of the memory pages that this process uses.)

We can compute summaries of the data from /proc/11666/smaps by using
awk:

[bloom@cat-in-the-hat ~]$ awk '/^Pss:/{SUM += $2} END{print SUM}' /proc/11666/smaps
101918

Firefox is really using just under 100 MB of memory.

Supposing we don't want to count libraries that are in use by other
processes at all:

[bloom@cat-in-the-hat ~]$ awk '/^(Private_Clean|Private_Dirty):/{SUM += $2} /^Swap:/{SUM -= $2} END{print SUM}' /proc/11666/smaps
99088

My memory use should drop by 96 MB or so if I close firefox right now.
(Probably more, since this doesn't account for memory owned by the X
server, on account of Firefox, and Firefox is notorious for wasting X
server memory.)

[bloom@cat-in-the-hat ~]$ free
             total       used       free     shared    buffers     cached
Mem:       3932216    1567328    2364888          0     258512     783544
-/+ buffers/cache:     525272    3406944
Swap:      2024148          0    2024148

Now let's close Firefox and confirm.

[bloom@cat-in-the-hat ~]$ free
             total       used       free     shared    buffers     cached
Mem:       3932216    1479960    2452256          0     258632     783380
-/+ buffers/cache:     437948    3494268
Swap:      2024148          0    2024148

We saved 85 MB of RAM. Not quite what I expected. What didn't I account
for?

For more information on /proc/$pid/smaps, see
http://bmaurer.blogspot.com/2006/03/memory-usage-with-smaps.html, the
proc(5) manpage, and the Linux::Smaps perl module.

--Ken
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.