[CentOS] Memory leak - how to investigate
Warren Young
warren at etr-usa.com
Mon Feb 3 20:36:18 UTC 2014
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.
More information about the CentOS
mailing list