Red Hat Bugzilla – Bug 51593
Kernel buffers leaking
Last modified: 2007-04-18 12:35:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010803
Description of problem:
Allocated memory increases with filesystem use. That is, if I boot my Dell
Inspiron 7000 laptop to runlevel 5, it will be using about 20MB plus
buffers and cache. If I run 'run-parts /etc/cron.daily', during slocate
especially, memory use will increase at a rate faster than buffers and
cache. Afterward, about 110MB of RAM will be in use, plus buffers and cache.
Steps to Reproduce:
1. Reboot, check RAM use
2. run-parts /etc/cron.daily (or anything that uses the filesystem a lot)
3. check RAM use again.
Actual Results: -----
total used free shared buffers cached
Mem: 223160 210852 12308 1400 16144 83944
-/+ buffers/cache: 110764 112396
Swap: 264560 0 264560
Memory use is much higher than it should be.
Expected Results: Buffers and cache are expected to increase, but
allocated memory is not.
I can reproduce this problem on a Dell workstation with a VIA IDE chipset
running RHL 7.1, 2.4.2-2 kernel and a Dell Inspiron 7000 laptop with an
Intel Corporation 82371AB PIIX4 IDE chipset running Roswell with either
kernel 2.4.2-2 or 2.4.6-3.1.
I don't beleive that the problem is any userspace application, as I can
switch to runlevel 1, remove all modules, and memory use is still very high
with only minilogd, init, and sh running.
Re-running run-parts runs all of the cron jobs again, but memory doesn't
increase significantly a second time.
Memory use may not be permanent. I logged in to the Dell workstation this
morning and about 55MB of RAM were used (plus b&c, of course). I rebooted
the workstation and logged in again, about 20MB were used. I ran the cron
jobs and check memory again, and about 88MB were used. So, it stands to
reason that over time, some of this memory is reclaimed, but I have not yet
figured out why or when this happens. It appears that this memory leak is
forcing applications into swap and hurting their performance, though.
If this is an "expected" behavior, where can a user find information about
how much of allocated memory is attributable to the kernel?
Created attachment 27457 [details]
process list and 'free' output at illustrating problem
There is some memory allocated in the inode-cache and directory-entry cache,
which are not visible in "buffer" or "cache", they are however released when the
system becomes low on memory. Especially the updatedb program fills these caches
agressively, as it does almost nothing more than looking through directories.
You can see the inode/dentry cache by doing
cat /proc/slabinfo | grep inode
I agree that it would be useful if there was a simpler way of seeing this memory
Seems to be it... I apologize for your time. You guys work Sundays? :)
'free' already has a line that clarifies memory use with regard to the buffers
and cache. Is there a reason it could not be extended to print an additional
line to clarify memory use with regard to slabs?
To follow up... I'm currently using 2.7.2-2 (Roswell 2) on a Dell laptop. It
doesn't seem like the inode and dentry caches are as quick to free as they
should be. That is, during normal use on a machine with ~220MB of RAM, I was
using 100MB of swap, when I was only using about 100MB of physical RAM in my
user processes. I noticed at first that the machine was really working slowly
for maybe a half an hour, before X stopped responding entirely for about 30
seconds while the system swapped. When X started responding again, I looked at
RAM use and the slabinfo file.
Since RAM use seemed *way* too high, I first saved the output of 'free' and
/proc/slabinfo into a file. Then, I exited out to single user mode and saved
the output of 'ps ax', 'free', and /proc/slabinfo to the file.
In single user mode, 'free' indicated that 113MB of RAM were in use, excluding
buffers and cache, and 30MB of swap were in use. I could understand if there
were cache in main RAM (even as much as 100MB), but why would the kernel keep
these buffers around long enough for 30MB of them to find their way into swap??
I'm attaching the file that includes what I saw. Would you consider this normal?
Created attachment 29675 [details]
memory use information