Bug 34917 - kernel memory leak
kernel memory leak
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.2
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Michael K. Johnson
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-05 15:34 EDT by Need Real Name
Modified: 2007-04-18 12:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-05 15:34:23 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)

  None (edit)
Description Need Real Name 2001-04-05 15:34:19 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT; IE4WDUS-
1999052001)


The kernel appears to allocate free memory to buffers which is never 
reclaimed.

Can be verified by using vmstat, top or looking in /proc/meminfo.  All 
kernels (6.2, 7.0, 7.1 beta) I've tested exhibit this problem.  Memory 
will continue to be allocated to the buffers until exhasted.  Once that 
happens swap space will be used and then not freed.  I discovered this 
testing sendmail performance (both kernel and sendmail were default 
installs).  It may also be the cause of sendmail instability.   

A simple test to exhibit this problem --

boot a system
cat /proc/meminfo > stuff

let the system sit overnight

cat /proc/meminfo


Check the memory usage.

Depending on the kernel and system used - I've looked at desktops to eight 
way servers, the systems will consume memory at different rates.  When 
presented with a heavy load from an application, it will happen more 
quickly.  At somepoint perfomance will be affected.  Stopping the 
application will not reclaim the space.  Simple utilities will use 
significant user and system cpu to execute

Reproducible: Always
Steps to Reproduce:
1.boot a system
2.capture info in /proc/meminfo
3.Let the system idle for 24 hours and compare information in /proc/meminfo
	

Actual Results:  From a desktop w/ 500MHz PIII running a default install 
from Redhat Linux 7 cd -- 2.2.16-22 

boot --

        total:    used:    free:  shared: buffers:  cached:
Mem:  129851392 42278912 87572480 66240512  3788800 20111360
Swap: 279576576        0 279576576
MemTotal:    126808 kB
MemFree:      85520 kB
MemShared:    64688 kB
Buffers:       3700 kB
Cached:       19640 kB
BigTotal:         0 kB
BigFree:          0 kB
SwapTotal:   273024 kB
SwapFree:    273024 kB


Overnight --


        total:    used:    free:  shared: buffers:  cached:
Mem:  129851392 88752128 41099264 67796992 47398912 15511552
Swap: 279576576        0 279576576
MemTotal:    126808 kB
MemFree:      40136 kB
MemShared:    66208 kB
Buffers:      46288 kB
Cached:       15148 kB
BigTotal:         0 kB
BigFree:          0 kB
SwapTotal:   273024 kB
SwapFree:    273024 kB


BTW --

I have a significant amount of data exhibiting the problem during 
application runs (on a 2 way using 2.2.14-6.1.1smp).  It is much more 
dramatic.  In this instance above 4K chunks are grabbed every 3 - 50 
minutes.  I did not capture a history as I wanted to make sure the machine 
was truly idle.


Expected Results:  MemFree, Buffers, MemShared and Cached would have 
similar sizes between the two captures.

bugzilla bug 19284 is a similar report  -- though reported as resolved I 
do not belive this is normal behavior.
Comment 1 Bill Nottingham 2001-04-05 23:56:17 EDT
It's being used for cache - see the 'buffers' entry in /proc/meminfo.
Comment 2 Need Real Name 2001-04-06 11:40:58 EDT
So, youre saying that when the system is in an idle state, it should continue 
to consume memory?  Why isn't it returned to MemFree?

Look at the attached log of vmstat collected in 1-minute intervals.  The 
beginning of the log shows the application starting up.  The end shows memory 
allocation after the process has finished.  Note the memory allocation and swap 
usage.  Is that normal?  Note the buffer allocation.  If I attempt to rerun the 
application it will die in short order.  Note this example is was run on a 
2.2.14-6.1.1smp kernel, however, I get similar results on later kernels.


   procs                      memory    swap          io     system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
 0  0  0      0 463432   6408  28084   0   0     0     0  100     6   0   0 100
 0  0  0      0 463432   6408  28084   0   0     0     0  100     6   0   0 100
 0  0  0      0 461840   7760  28204   0   0     0    10  125    23   2   1  98
 9  0  0      0 389044  39368  36092   0   0     0   273  906   468  52  13  36
22  0  0      0 302820  84584  36804   0   0     0   341 1161   434  66  18  16
 4  0  0      0 304244 124860  31240   0   0     0   290  821   329  54  18  28
 1  2  0      0 286432 169488  28848   0   0     0   276  786   281  61  15  23
18  0  0      0 222092 227004  29664   0   0     0   286  914   283  69  17  15
12  0  0      0 162336 281196  29768   0   0     0   323  791   285  75  17   8
 8  0  0      0 120600 330268  28412   0   0     0   303  581   299  77  16   7
13  0  0      0  61572 384184  30704   0   0     0   284  434   302  80  16   4
13  0  0      0   8252 437784  29356   0   0     0   313  441   302  83  17   0
19  0  0   1128   3304 442160  31148   0  19     4   338  429   301  82  17   1
12  6  0   1128   2412 440756  31428   0   0     0   321  434   298  80  20   0
11  1  0   1128   4304 441328  31364   0   0     0   333  425   323  79  21   0



 7  0  0   1512  17332 388908  63000   0   0     1    47  110    88  39  61   0
 8  0  0   1512  13488 388908  66564   0   0     0    20  107    63  37  63   0
11  0  0   1512  57708 388908  20372   0   0     0    20  106    62  35  65   0
 2  0  0   1512  63968 388908  20164   0   0     0    23  108    58  39  47  15
 3  0  0   1512  64116 388908  19808   0   0     0     3  105    56  35  36  29
 2  0  0   1512  64680 388908  19992   0   0     0     4  104    48  25  26  50
 1  0  0   1512  65312 388908  19872   0   0     0     4  106    37  27  31  43
 0  0  0   1512  66656 388908  19792   0   0     0     1  102     8   4   3  93
 0  0  0   1512  66656 388908  19792   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66656 388908  19792   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66656 388908  19792   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     1     1  101     7   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     6   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     6   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     1  101     6   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     5   0   0 100
 0  0  0   1512  66420 388908  20092   0   0     0     0  100     5   0   0 100








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