[clug] Help: Memory Evaporating!
Alex Satrapa
grail at goldweb.com.au
Tue Dec 21 04:42:46 GMT 2004
On 21 Dec 2004, at 13:00, Steve Walsh wrote:
> It turns out my main issue was badly configured mod_ssl entries. Try
> using a shared memory session cache - like
>
> SSLSessionCache shmcb:logs/ssl_gcache_data(512000)
> SSLSessionCacheTimeout 300
>
> Other than that, what flavour linux/version perl &/or apache?
It's not an SSL problem - we're not using SSL (for whatever reason) for
these connections.
Apache 1.3.26 (it's a home-rolled one, but I don't know where the
config.h file is, and I don't know what special options are required,
so I can't go installing the Debian version)
PostgreSQL 7.3.2 (again, home-rolled, no config.h and no idea why it's
home rolled, so I can't install the Debian version)
But I've managed to find where the memory was disappearing to - by
running "tail -f /var/log/apache/*.log &" and "vmstat 1 &" I got
interleaved results of both the Apache log files and the memory & I/O
performance. It looks to me as though some external process is being
launched (part of the CGI & DBI stuff), loading up 20MB of data from
the database, then mostly disappearing except for some residual. So
I've found the culprit, but only by observing the side-effects. I will
now have the joy of following 4000 lines of Perl code in the debugger
to find what it is that is holding on to all that memory. And perhaps I
should look at tuning the database too. But both of those are topics
for discussion in other forums.
What has me flummoxed is that the memory doesn't all return to the
'free' pile (heap?) until several seconds after the web server has been
killed (I obviously wasn't patient enough before posting to the list,
sorry) - but there is no process visible that holds that memory before
or after I stop the Apache server.
So I'm still wondering - is there any way of digging into the kernel
using what's presented to me in user space, in order to find out where
all the memory is going? "ps" won't tell me, and I haven't found the
right place to look in /proc. I'd like to be able to get a listing of
all the allocated blocks of RAM, and what process ID they were
allocated to. That would be a gift from the Linux gods. I could use
said list to then monitory the progress of the CGI to see which bits of
code are the "grab and don't release" offenders. I suspect that some
task is allocating memory, grabbing a database handle, then not freeing
either and thus being condemned to live as a soulless zombie, consuming
the brains of my computer.
Alex
More information about the linux
mailing list