A very important aspect of performance
tuning is to make sure that your applications don't
use too much memory. If they do, you cannot run many servers, and
therefore in most cases, under a heavy load the overall performance
will be degraded. The code also may leak memory, which is even worse,
since if the same process serves many requests and more memory is
used after each request, after a while all the RAM will be used and
the machine will start swapping (i.e., using the swap partition).
This is a very undesirable situation, because when the system starts
to swap, the performance will suffer badly. If memory consumption
grows without bound, it will eventually lead to a machine crash.

The simplest way to figure out how big the processes are and to see
whether they are growing is to watch the output of the
top(1) or
ps(1)utilities.

This starts with overall information about the system and then
displays the most active processes at the given moment. So, for
example, if we look at the httpd_perl processes,
we can see the size of the resident (RSS) and
shared (SHARE) memory segments.[35] This sample was
taken on a production server running Linux.

[35]You can tell top to sort the entries by
memory usage by pressing M while viewing the
top screen.

But of course we want to see all the apache/mod_perl processes, and
that's where ps(1) comes in.
The options of this utility vary from one Unix flavor to another, and
some flavors provide their own tools. Let's check
the information about mod_perl processes:

Now you can see the resident (RSS) and virtual
(VSZ) memory segments (and the shared memory
segment if you ask for it) of all mod_perl processes. Please refer to
the top(1) and ps(1)
manpages for more information.

You probably agree that using top(1) and
ps(1) is cumbersome if you want to use
memory-size sampling during the benchmark test. We want to have a way
to print memory sizes during program execution at the desired places.
The GTop module, which is a Perl glue to the
libgtop library, is exactly what we need for that
task.

You are fortunate if you run Linux or any of the BSD flavors, as the
libgtop C library from the GNOME project is
supported on those platforms. This library provides an API to access
various system-wide and process-specific information. (Some other
operating systems also support libgtop.)

With GTop, if we want to print the memory size of
the current process we'd just execute:

use GTop ( );
print GTop->new->proc_mem($$)->size;

$$ is the Perl special variable that gives
the process ID (PID) of the currently running process.

If you want to look at some other process and you have the necessary
permission, just replace $$ with the other
process's PID and you can peek inside it. For
example, to check the shared size, you'd do:

We have just printed the memory sizes of the process: the real, the
shared, the virtual, and the resident (not swapped out).

There are many other things GTop can do for
you—please refer to its manpage for more information. We are
going to use this module in our performance tuning tips later in this
chapter, so you will be able to exercise it a lot.

If you are running a true BSD system, you may use
BSD::Resource::getrusage
instead of GTop. For example:

print "used memory = ".(BSD::Resource::getrusage)[2]."\n"

For more information, refer to the BSD::Resource
manpage.

The
Apache::VMonitor module, with the help of the
GTop module, allows you to watch all your system
information using your favorite browser, from anywhere in the world,
without the need to telnet to your machine. If
you are wondering what information you can retrieve with
GTop, you should look at
Apache::VMonitor, as it utilizes a large part of
the API GTop provides.