[CentOS] Memory leak - how to investigate

Mon Feb 3 20:36:18 UTC 2014
Warren Young <warren at etr-usa.com>

On 2/3/2014 12:59, m.roth at 5-cent.us wrote:
> Kwan Lowe wrote:
>>> Mem:   1361564k total,  1264324k used,    97240k free,     8428k buffers
>>>
>> That doesn't look like a lot of memory.. Possible to add another .5G or
>> so?
>
> 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.

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

Many web stacks are RAM pigs.  I don't mean "they can use a lot of RAM 
productively," I mean they're based on inefficient or misapplied 
technologies that load a bunch of pointless things into RAM.  Unless 
these things get swapped back out, they're ballooning your VM for no 
useful purpose.

One web stack I used in the past had *GUI libraries* linked into its 
core executable.  This, for software designed to run on headless VPSes!

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.

That's another aspect of web stacks being RAM pigs: it is *possible* to 
make a pre-forking web stack share a lot of RAM among the forks, but it 
doesn't happen by itself.  If you use naive defaults and naive 
development practices, you can end up with each fork being essentially 
independent copies of the whole web stack.  This not only chews up RAM 
to no good end, it means each fork takes longer to start, which hurts 
site performance.

Web site tuning is hard.