> Why, reinvent the wheel? I wrote Apache::VMonitor (grab from CPAN) that
> does all this and more (all but tail -f) I use it all the time, saves me a
> lot of time, since I don't have to telnet!
Ok - I will try to look into that when I get time.
> > 2) Open up and hack Apache::SizeLimit and have it do a stack dump
> > (Carp::croak) of what's going on... there may be some clue there.
I've done this (In a PerlRequire'd file):
--------------
# Use apache process size limitation
use Apache::SizeLimit;
$Apache::SizeLimit::MAX_PROCESS_SIZE = 9000;
$Apache::SizeLimit::CHECK_EVERY_N_REQUESTS = 3;
---------------
and 'PerlCleanupHandler Apache::SizeLimit' in httpd.conf.
The server is still getting restarted by the uptime/swapfile monitor, so I'm
not sure if this is having an effect.
I'll look into opening up sizelimit and doing a stack dump as soon as I get
time.
> Apache::GTopLimit is an advanced one :) (you are on Linux, right?) but
> Apache::SizeLimit is just file
I had some problems with GTop, I was trying to use Apache::VMonitor, I
downloaded and installed libgtop and the other packages needed (Forget which
now) and tried to install VMonitor, but it failed on make test, couldn't
locate one of the packages I definitely installed, a graphics manipulation
one from memory, but i'm writing this e-mail offline so I can't check :)
> 3) try running in single mode with 'strace' (probably not a good idea for
> a production server), but you can still strace all the processes into a
> log file
Well I might be able to get a server running in single mode on a different
port and try that, it would be worth the information gained if I can sort
this problem out :)
> 4) Apache::Leak ?
Ok, will look at that too.
--
James Furness <[EMAIL PROTECTED]>
ICQ #: 4663650
