[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.


More information about the linux mailing list