Finding and Trimming Linux Bloat - page 2

Analyzing Linux Memory

If you examine your system's memory use with a program like ps or top, you'll typically see two numbers. ps calls them RSS and VSZ, while top calls them RES and VIRT.

For instance, ps might display something like this:

$ ps uw --sort=-rss
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
akkana    6813  0.4  5.1 315160 158708 tty1    Sl   09:19   3:21
firefox-bin
akkana   16883 10.6  2.4 104464 75824 tty1     Sl   22:31   0:02 /usr/bin/gimp
akkana   32549  0.0  0.6  33832 18832 tty1     S    18:52   0:05 xchat
akkana    6678  0.1  0.5  25552 16372 tty1     S    20:11   0:01 emacs
akkana    4688  0.0  0.4  29272 14312 tty1     Sl   08:56   0:02 python twit
akkana    4039  0.0  0.2  12408  7344 tty1     S    08:55   0:02 openbox
akkana     511  0.0  0.1   9460  5680 pts/0    S+   18:54   0:00 mutt
akkana    7063  0.0  0.1   8796  4932 tty1     S    09:21   0:00 xterm
akkana    4033  0.0  0.1   9232  3832 tty1     S    08:55   0:00 xterm
akkana    4035  0.0  0.0   5524  2844 tty1     S    08:55   0:00 python -u mybeepd crickets.wav
akkana    7064  0.0  0.0   4452  2568 pts/1    Ss   09:21   0:00 -tcsh
akkana    3849  0.0  0.0   4188  2092 tty1     S    08:55   0:00 -tcsh
akkana    4041  0.0  0.0   4004  2084 pts/0    Ss   08:56   0:00 -tcsh
akkana    3944  0.0  0.0   3504  1548 tty1     S+   08:55   0:00 /bin/bash /usr/bin/startx
akkana    7952  0.0  0.0   2700   940 pts/1    R+   20:30   0:00 ps uw --sort=-rss

So, what are those numbers? And is Firefox really using 315 megabytes?

RSS stands for Resident Set Size. It's theoretically the amount of physical RAM the program is actually taking in your system right now, not counting anything that might be swapped to disk. In practice, it's a little more complicated than that, as you'll see in a moment.

VSZ stands for Virtual SiZe -- the total memory of the process, all its code, data and libraries, whether it's currently loaded in memory or swapped to disk.

So in other words, VSZ is RSS plus whatever is swapped to disk. Right?

Well, no. You can find out what's swapped with free:

$ free
             total       used       free     shared    buffers     cached
Mem:       3103496    1274712    1828784          0     137016     777512
-/+ buffers/cache:     360184    2743312
Swap:      2249060          0    2249060

The second line shows how much swap is being used: none, on my system right now. Yet Firefox is using 315M of VSZ but only (only!) 159M of RSS. How can that be?

What the ps and top man pages don't tell you is that there are other types of memory included in VSZ. For instance, when a program makes a large large memory allocation request, the kernel may not allocate all of it right away -- it might just reserve it in case the program ever actually tries to access that memory. So VSZ represents RSS plus swapped memory plus memory that the program thinks it might need to use some day but actually may never touch.

Okay, so that VSZ number is bogus. Firefox isn't really using 315M. Whew! What about that 159M of RSS?

Well, there are mitigating factors there too. The biggest is shared libraries.

I'm sure you've encountered them before. A shared library (also called a dynamically loaded library) is a file like libX11.so.6 or /usr/lib/libgtk-x11-2.0.so.0, where so stands for shared object. The point of a shared library is that you can have common code -- like the routines that talk to the X server and create windows, read JPG files, or handle fonts -- that are shared among lots of apps. So Firefox, GIMP, gedit and abiword could all be using the same X11, gtk+, pango and cairo libraries, and you'd only need those libraries loaded once each in memory instead of four times each.

But Linux memory applications aren't so good at figuring out what parts of memory are shared. When ps tells you that Firefox is taking up 159M of RSS and GIMP is taking up 76M, it's counting some shared libraries twice.

How much memory does that represent? That's not an easy question to answer using programs like ps. In the next installment I'll talk about some ways of examining how much memory your processes are really using.

Akkana Peck is a freelance programmer whose credits include a tour as a Mozilla developer. She's also the author of Beginning GIMP: From Novice to Professional.