Re: Who eats my buffers?! (kernel leaks memory?)
I'm sure this is a FAQ somewhere, but I can't find it on my system
right off hand. So...
Christian Hammers <ch@westend.com> writes:
CH> I have a serious problem. One of the servers I administrate seems to
CH> have a buffer leak. free and vmstat show me that the buffer size
CH> increases by some K every second leading to a 15M memory loss per hour.
CH> I'm currently running a PII with 256M RAM and kernel 2.2.15
CH> (latest).
Yup, that sounds about right. Except that it's not a problem.
So memory in your system can be used for one of a few things. The
kernel might be using it directly; there's probably about a meg
missing from your 'free' total line for this. You can minimize this
by reducing the number of modules you have loaded and the amount of
stuff you have built into the kernel. With 256MB of RAM, though, this
isn't likely to be a huge amount.
Memory can be used by program data and program code. The latter can
be shared between multiple instances of the same program, and shared
libraries can be shared between multiple programs using the same
library, so all of this shows up in the "shared" column of 'free'.
Unsharable program data shows up in the "used" column (along with
everything else).
At this point, we've accounted for all of the memory that the system
needs for programs. The third line of 'free's output (-/+
buffers/cache) has this information. On my system, there's 56MB of
RAM, and 21588K is actually used.
The kernel could just let the rest sit there and be wasted. Instead,
it takes memory as is available and uses it as disk cache space. This
makes the system run faster (since hopefully data needed from the disk
will already be in memory), and has negligible cost (it's using memory
that otherwise would be completely unused). If there's suddenly more
demand for memory, the kernel can just throw away buffers and cache
(the data exists for real on the disk) and use that space for programs
and data.
CH> Background is that it crashed on it's first day in production service with
CH> a out-of-memory error displayed at the console - after two month working
CH> idle in test mode. After that I upgraded this morning from 2.0.36 to 2.2.15.
CH> I can't tell how exaktly the buffer behaviour was in 2.0.36 :-(
The buffer behavior was the same in 2.0.36. :-) What exactly died,
and what error exactly did it get? If you have a really large
process, it might be running into the system limits; try typing
'ulimit -a' in bash (or other Bourne-shell derivatives) and see if you
might be running into limits for various things. You can also use
ulimit to change the limits; see the shell's man page for details.
(In C-style shells, the relevant command is 'limit'.)
--
David Maze dmaze@mit.edu http://www.mit.edu/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
Reply to: