Bug 51593 - Kernel buffers leaking
Kernel buffers leaking
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-12 15:40 EDT by Gordon Messmer
Modified: 2007-04-18 12:35 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-06 12:56:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
process list and 'free' output at illustrating problem (2.26 KB, text/plain)
2001-08-12 15:42 EDT, Gordon Messmer
no flags Details
memory use information (11.77 KB, text/plain)
2001-08-27 02:53 EDT, Gordon Messmer
no flags Details

  None (edit)
Description Gordon Messmer 2001-08-12 15:40:30 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.

How reproducible:
Always

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:  -----
$ free
             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.

Additional info:

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?
Comment 1 Gordon Messmer 2001-08-12 15:42:39 EDT
Created attachment 27457 [details]
process list and 'free' output at illustrating problem
Comment 2 Arjan van de Ven 2001-08-12 15:47:36 EDT
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
accounted.
Comment 3 Gordon Messmer 2001-08-12 16:15:56 EDT
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?
Comment 4 Gordon Messmer 2001-08-27 02:51:56 EDT
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?
Comment 5 Gordon Messmer 2001-08-27 02:53:55 EDT
Created attachment 29675 [details]
memory use information

Note You need to log in before you can comment on or make changes to this bug.