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.
It's being used for cache - see the 'buffers' entry in /proc/meminfo.
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