[sf-lug] sf-lug Digest, Vol 31, Issue 20
rick at linuxmafia.com
Mon Jun 9 10:01:24 PDT 2008
Yesterday, I wrote:
> Particularly on a RAM-constrained machine:
> o You need to know _why_ you're running each process (i.e., know what
> happens if you kill it, and know why that would be A Bad Thing).
I really should have elaborated on the above, and will do so now:
Let's say (and this particular example happens _a great deal_ on low-RAM
systems you've just installed Debian onto someone's 64MB RAM P200 laptop,
and the output of "ps auxw | more" (the process table) includes a line
for process "portmap", something like this:
daemon 11064 0.0 0.1 1664 456 ? Ss May22 0:00 /sbin/portmap
The laptop's running OK, and you're thinking: I don't know much about
"portmap", and don't know if it's a needed process or not. How do I tell?
Good question. The way you tell is: Kill it ("killall portmap", run as
the root user), make sure the process is indeed gone, and see if
anything is no longer working that you care about.
That's the core of the matter, right there: If you kill a process and
don't miss it, then by a functional definition it's an unnecessary
process, and you should go disable its autostartup for subsequent
Now, the above might strike you as a bit hasty: Might the effects be
subtle and noticed only later after you forgot what you'd killed and
why? Probably not but maybe yes. Which is one reason why you should
_take notes_ while setting up a system. Those notes are (then) your
safety net, enabling you to know what you did and if necessary
(Also, you would want to Web-search the process name. If you did, you'd
find out that "portmap" is a network service used by Network File
System = NFS, Network Information System = NIS, GNOME's "FAM" = file
access monitor, and some very obscure other services. You would likely
conclude that, indeed, you don't need it.)
> o In order to understand where the RAM goes, you need to be able to
> read and interpret the RAM statistics of "ps auxw" or some
> equivalent command. In particular, you need to understand what the
> "RSS" and "Shared" columns mean.
"RSS" here does not stand for Really Simple Syndication, but rather
Resident Set Size, which is the amount of _physical_ (as opposed to
swap) memory that the process is taking up at the moment.
The other field I was thinking of in "ps" is not called "Shared" (which
is a field in the similar "top" utility) but rather "VSZ" which stands
for "virtual size". As you will see here...
...it's _supposed_ to be the footprint of the entire process including
virtual memory (swap), but, for mindnumbingly obscure reasons having to
do with kernel memory-management tricks, it's not a very reliable
measure of that total process size.
A bit more meaningful is the SHR (shared memory) field in the output of
"top". E.g., here are all the "named" (BIND9) instances running on my
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
697 bind 18 0 3996 3584 1496 S 5.5 1.4 13:18.55 named
695 bind 9 0 3996 3584 1496 S 0.0 1.4 0:00.01 named
696 bind 9 0 3996 3584 1496 S 0.0 1.4 0:00.18 named
698 bind 9 0 3996 3584 1496 S 0.0 1.4 0:07.30 named
699 bind 10 0 3996 3584 1496 S 0.0 1.4 1:54.60 named
The "RES" = Resident Set Size of each instance is 3.5MB (reporting units
being kB), and shared memory is 1.5MB. Although SHR is just memory that
the process _potentially_ shares with other processes, it seems a very
fair bet, here, that it's truly common code among the BIND9 instances.
So, each process's true full size is probably somewhere between the RSS
("RES") figure of 3.5MB and the "VIRT" (same as ps's "VSZ") size of 4MB,
with about 1.5MB common between them. So, a rough estimate of RAM
grabbed by BIND9 is:
(3.75MB - 1.5MB) * 5, plus shared code of 1.5MB = 12.75MB.
It's possible to make better estimates of true RAM usage (see URL,
above), but the above sort of shirtsleeve calculation tends to be good
More information about the sf-lug