[CentOS] Memory leak - how to investigate

Mon Feb 3 21:49:48 UTC 2014
Kwan Lowe <kwan.lowe at gmail.com>

On Mon, Feb 3, 2014 at 3:36 PM, Warren Young <warren at etr-usa.com> wrote:

> > Ah! I missed that. Is it actually the case that your server doesn't even
> > have 2G of RAM? That's a *real* problem.
>
> Small RAM limits with strange values like 1.3 GB are normal for VMs.
>
> This is true. I can start up VMs with under 256M and do so quite often.
Looking at the non-shared memory in the list of procs posted, however, it
looks like that server at least is running pretty thin.

Rather than give the VM more dedicated RAM, have you tried adding more
> swap, Jussi?  Your system may be well-tuned, not I/O bound all the time
> swapping to disk, but that doesn't mean swap isn't useful.


Interesting:

21463 total pagecache pages
20882 pages in swap cache
Swap cache stats: add 1523887, delete 1503005, find 201987/297332
Free swap  = 0kB
Total swap = 3014648kB

In this case I'm more inclined to limit the number of processes rather than
increasing page space. Adding swap will delay the OOM, which is good, but
performance will suffer.


>  Modern OSes
> pretty much depend on having some swap space.  If nothing else, it lets
> the OS move some little-used bits of code out of RAM, so the RAM can be
> used for the computer's real work.
>

Yes!  You don't know how many times I've heard, "I have 64G of memory! Why
do I need swap?"  There are some benefits to running swapless though. I've
dinked around with the overcommit and other memory options for some
workloads.

>
> Another thing to look into is how many forks or threads your web stack
> uses.  More is better for speed, up to the point where you run out of
> RAM, at which point your web stack slows to a crawl or dies.  If each
> fork takes 500 MB, and you've got it set to use 3 forks, you're already
> running into swap space, unless there's some serious RAM sharing going
> on among the forks.
>
> :)  Just had this conversation about spinning up Websphere JVMs to
"increase performance"...


>
> Web site tuning is hard.
>
>
:P