[GRLUG] Memory leak

Adam Tauno Williams awilliam at whitemice.org
Wed Sep 26 18:32:28 EDT 2012


On Wed, 2012-09-26 at 15:07 -0500, Don Ellis wrote: 
> I think one thing we'd like (Lee & I) is some simple recipes for
> people with less than massive experience at process monitoring. We
> hear the terms mentioned, with "use this tool or that tool" but no
> guidelines for some common conditions to look for. Are there specific
> symptoms for specific kinds of pathology that would give hints that
> something is not as it should be?
> One caveat I see in text on this subject is: look for unexpected
> results, as some process will be expected to show these conditions,
> and can be ignored. Other process should not do that, and these
> conditions would indicate these processes are outside normal expected
> range. 

What you describe is impossible to provide.

I already posted several suggestions and queries to which you did no
respond
<http://shinobu.grlug.org/pipermail/grlug/2012-September/012598.html>.

There is also <http://www.wmmi.net/documents/Debugging2012.pdf> - you
should go through that.

> On Wed, Sep 26, 2012 at 1:51 PM, L. V. Lammert <lvl at omnitec.net> wrote:
> > Been having problems with a server blocking (i.e. %wa > 90%), .. I rebooted
> > it this AM and it's back to normal!
> > Memory Usage is now < 1GB (2GB physical, 4GB swap), where last night it was
> >> 3GB total!

What does an output of "free -t" look like?  If you just run "top" you
can sort by memory utilization [if this is actually a memory leak].
Just "M" will sort my Resident Memory.  The "dstat" previously
recommended [and ignored] will show you if paging is occurring;  the
more commonly available vmstat command will tell you same thing as well.

vmstat -a 5

> As all of the processes are fairly static (it's a Nagios box),
> > with some reverse ssh tunnels and a miniscule MySQL database.
> > Does anyone know of a way to get more information about where the leak is
> > occurring, if that is indeed the problem?

If it is really a user level memory leak the culprit will be obvious.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://shinobu.grlug.org/pipermail/grlug/attachments/20120926/73e20859/attachment.pgp>


More information about the grlug mailing list