Bug 51593
| Summary: | Kernel buffers leaking | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Gordon Messmer <gordon.messmer> | ||||||
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Brock Organ <borgan> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 7.1 | ||||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | i386 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2003-06-06 16:56:31 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
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 accounted. 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
|
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?