How to get more information on CGIs I'm watching with Unix's "top" command

[AidanLee]

Hello the Monestary,

So I'm monitoring a client's web site via top and the cgis for the site are chugging merrily (and speedily) along, except that once and a while one of them starts taking over the server's available memory and driving the load on the server way up. Now, this is just the same script (incidentally, index.cgi) as the happy processes, but apparently the path info and potentially the query string are causing a condition that isn't happening the rest of the time.

Problem is, I can't see what the path info and query string are by watching top, so I have no idea what values I should profile with.

So here's my plea for help. I can clearly see the rogue processes, PID and all, but I'm at a loss as to how to find out more about them for debugging and profiling purposes. Any ideas?

[Fletch]

Presuming it's really CGI (not FastCGI) you should be able to use the ps command's e flag (again presuming the OS in question's ps supports BSD-y arguments) to dump the process' environment where you'd see things like path info and query strings and what not. You may also find several w's useful to dump more of the environment.

Alternately if the OS supports it and permissions allow it you may be able to extract information from the /proc filesystem (e.g. on Linux you could look in /proc/##/environ).

[AidanLee]

Yes, Fedora Core's ps accepts BSD style arguments. ps e p PID worked like a charm. Thanks.

[CountZero]

I think Apache-top is exactly what you need. Beware however, it is written in Python! ;-)

[f00li5h]

if you don't mind tamperig (just a little), you can hack this onto the top of the script. You may also be able to stick it in play with a PerlModule or similar directive in an apache config...

BEGIN {     
    $0 = $0 . join ' - '@ENV{qw{QUERY_STRING PATH_INFO}} 
}

[spatterson]

What abount modifying index.cgi slightly so that every time it runs, it append the query string to a logfile? On second thoughts I think Apache will do this anyway, so have a look at your Apache access.log too.

[AidanLee]

I considered that (using the access log), but i needed to identify which PID was the culprit, as there could be many instances of index.cgi running at the same time.