5.10.2.1. Prerequisites and configuration

ExtendedStatus On

Turning on extended mode will add a certain overhead to each request's response time. If every millisecond counts, you may not want to use it in production.

You also need Time::HiRes and GTop to be installed. And, of course, you need a running mod_perl-enabled Apache server.

To enable Apache::VMonitor, add the following configuration to httpd.conf:

<Location /system/vmonitor>
    SetHandler perl-script
    PerlHandler Apache::VMonitor
</Location>

The monitor will be displayed when you request http://localhost/system/vmonitor/.

You probably want to protect this location from unwanted visitors. If you are accessing this location from the same IP address, you can use a simple host-based authentication:

<Location /system/vmonitor>
    SetHandler perl-script
    PerlHandler Apache::VMonitor
    order deny,allow
    deny  from all
    allow from 132.123.123.3
</Location>

Alternatively, you may use Basic or other authentication schemes provided by Apache and its extensions.

You should load the module in httpd.conf:

PerlModule Apache::VMonitor

or from the the startup file:

use Apache::VMonitor( );

You can control the behavior of Apache::VMonitor by configuring variables in the startup file or inside the <Perl>section. To alter the monitor reporting behavior, tweak the following configuration arguments from within the startup file:

$Apache::VMonitor::Config{BLINKING} = 1;
$Apache::VMonitor::Config{REFRESH}  = 0;
$Apache::VMonitor::Config{VERBOSE}  = 0;

To control what sections are to be displayed when the tool is first accessed, configure the following variables:

$Apache::VMonitor::Config{SYSTEM}   = 1;
$Apache::VMonitor::Config{APACHE}   = 1;
$Apache::VMonitor::Config{PROCS}    = 1;
$Apache::VMonitor::Config{MOUNT}    = 1;
$Apache::VMonitor::Config{FS_USAGE} = 1;

You can control the sorting of the mod_perl processes report by sorting them by one of the following columns: pid, mode, elapsed, lastreq, served, size, share, vsize, rss, client, or request. For example, to sort by the process size, use the following setting:

$Apache::VMonitor::Config{SORT_BY}  = "size";

As the application provides an option to monitor processes other than mod_perl processes, you can define a regular expression to match the relevant processes. For example, to match the process names that include "httpd_docs", "mysql", and "squid", the following regular expression could be used:

$Apache::VMonitor::PROC_REGEX = 'httpd_docs|mysql|squid';

We will discuss all these configuration options and their influence on the application shortly.

5.10.2.2. Multi-processes and system overall status reporting mode

This mode comes with the following features:

5.10.2.3. Single-process extensive reporting system

• Process type (child or parent), status of the process (Starting, Reading, Sending, Waiting, etc.), and how long the current request has been being processed (or how long the previous request was processed for, if the process is inactive at the moment the report was made).

• How many bytes have been transferred so far, and how many requests have been served per child and per slot. (When the child process quits, it is replaced by a new process running in the same slot.)

• CPU times used by the process: total, utime, stime, cutime, cstime.

For all processes (mod_perl and non-mod_perl), the following information is reported:

• General process information: UID, GID, state, TTY, and command-line arguments

• Memory usage: size, share, VSize, and RSS

• Memory segments usage: text, shared lib, date, and stack

• Memory maps: start-end, offset, device_major:device_minor, inode, perm, and library path

• Sizes of loaded libraries

Just as with the multi-process mode, this mode allows you to automatically refresh the page at the desired intervals.

Figure 5-3. Extended information about processes: general process information

Figure 5-4. Extended information about processes: memory usage and maps

Figure 5-5. Extended information about processes: loaded libraries

5.10.3.1. mod_perl server watchdogs

The crontab entry for 30-minute intervals would read:

5,35 * * * * /path/to/the/apache.watchdog >/dev/null 2>&1

Another approach is to use the Perl LWP module to test the server by trying to fetch a URI served by the server. This is more practical because although the server may be running as a process, it may be stuck and not actually serving any requests—for example, when there is a stale lock that all the processes are waiting to acquire. Failing to get the document will trigger a restart, and the problem will probably go away.

We set a cron job to call this LWP script every few minutes to fetch a document generated by a very light script. The best thing, of course, is to call it every minute (the finest resolution cron provides). Why so often? If the server gets confused and starts to fill the disk with lots of error messages written to the error_log, the system could run out of free disk space in just a few minutes, which in turn might bring the whole system to its knees. In these circumstances, it is unlikely that any other child will be able to serve requests, since the system will be too busy writing to the error_log file. Think big—if running a heavy service, adding one more request every minute will have no appreciable impact on the server's load.

So we end up with a crontab entry like this:

* * * * * /path/to/the/watchdog.pl > /dev/null