[sf-lug] sf-lug Digest, Vol 31, Issue 20

[Rick Moen]

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
bootups.

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
backtrack.

(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...

http://lwn.net/Articles/230975/

...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
server:

  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
enough.