Memory Leak Issues

[Glenn Steen]

On 25/10/06, Matt Kettler <mkettler at evi-inc.com> wrote:
> Kaplan, Andrew H. wrote:
> > Hi there --
> >
> > I am running Fedora Core 5 that was hardened by Bastille Linux on a system with
> > 1.5 GB of RAM. The system functions as an e-mail server running Sendmail 8.13.7,
> >
> > along with MailScanner 4.55.9, SpamAssassin 3.1.0, and ClamAV 0.88.5.
> >
> > I have noticed over time, via the free -m command, that the amount of cached RAM
> > is going up. This results in the amount of free memory going down to where there
> > is almost nothing left.
>
> That should be normal. Ideally your system should have 0 bytes of truly free,
> unused physical memory.
>
> All of your "free" memory should be used as cache, which can be quickly
> reallocated whenever an application needs memory. The cache in Linux is highly
> dynamic and this can happen on-demand with very little overhead.
>
> So keep in mind, cache ram is not memory that's permanently tied up in that
> task. It's simply "on loan" to the cache pool until it is needed elsewhere.
>
>  The end result has been the system to periodically
> > hanging, which forces me to reboot the server.
>
> That should not be related. Since the cache ram will be reallocated as soon as
> it's needed, you're not really out of ram.
>
> Fundamentally your "free to be used by applications when needed" memory is
> free+cache, not just free.
>
> Free simply means "not used for anything at all" or "wasted due to lack of
> kernel efficiency".
>
> >
> > Does anyone know of any memory leak issues with Fedora Core 5 or the
> > applications  that I mentioned above? Thanks.
> >
>
> No, it's normal behavior of the linux kernel. It's just trying to make the most
> of the available physical memory by temporarily turning the otherwise idle
> memory into disk cache.
Good summary so far.

> For what it's worth, modern MS Windows does the same thing, but less
> aggressively, because there's more overhead associated with reducing the cache size.
This is a first.... "Justifying" Linux kernel behaviour with the
argument that Bill is doing the same... Jesus! What is the world
coming to!? :-D
Wether the Redmond crowd has picked up a good idea, or not, is immaterial.
This behaviour is a _really_ good idea and stands (as you showed in
the first part Matt) well on its own:-).

As to the "random hang", what made you think memory depletion/swapping
was the culprit Andrew?
Did you have a vmstat or sar running (writing to file) that gave
indication of this?
Do you get any "Out of memory" in syslog and/or messages?
With the info we have, we can't really help you, apart from some
generalities and pointing toward the tools you should be looking at
(top is good for some things, but is generally not that suitable in
situations like this).
As to the generalities.... Always suspect your hardware;-). And look
closely at what preceded the "bad behaviour" (like a kernel or driver
update). Test your RAM (with a good memory tester like Memtest86),
excersise your HDDs (Bonnie could be used for that, as well as dd
(with large counds and bs set to something sane for the HDD) from
different pseudo-devices (/dev/zero, /dev/random ...)). Oh well,
that's enough platitudes for now:-)

Cheers (All that talk of drinking in some threads on this list made me
thirsty....:-)
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se