Bug 36624
| Summary: | RFE: Inode cache needs tuning | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Leos Bitto <bitto> |
| 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 00:29:11 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: | |||
I have a machine at home with several FAT partitions, I'll try to reproduce this there. Oops, forget FAT, maybe I should have thought a bit more before submitting this report. Now I unmounted all my FAT partitions, run updatedb (aka slocate.cron) and surprise - the bug is still there. :( Could you do "dd if=/dev/zero of=/tmp/someweirdfile bs=1024 count=1000024" (eg create a 1 gb file) and then "rm /tmp/someweirdfile" to see if this is just a cache or a real leak ? :-)))) Good try, but it's really not that easy - please do look at the /proc/meminfo dump I sent. I tried that dd you suggested, but with with only 600 MB file - I don't have 1 GB free space right now. No problem appeared - sure, the whole RAM got filled with cache, but that's OK. The question is, is the "leak" still there after this command? There is one cache that isn't accounted in "buffers" or "cache" and that is the "inode" cache (it's actually 2 caches in the kernel). It might be that they are not trimmed agressively enough. The "dd" should provoke them being trimmed anyway. After dd everything seems to be fine, no leak appears.
Here's /proc/meminfo:
total: used: free: shared: buffers: cached:
Mem: 525586432 119160832 406425600 0 8896512 50581504
Swap: 542826496 0 542826496
MemTotal: 513268 kB
MemFree: 396900 kB
MemShared: 0 kB
Buffers: 8688 kB
Cached: 49396 kB
Active: 57268 kB
Inact_dirty: 816 kB
Inact_clean: 0 kB
Inact_target: 4840 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 513268 kB
LowFree: 396900 kB
SwapTotal: 530104 kB
SwapFree: 530104 kB
If I understand it correctly, the dd command doesn't stress the inode cache,
does it?
It doesn't. But it stresses the normal cache which then will ask the inode cache to free up it's memory. So if the leak is gone after doing the "dd", it is the inode cache. It then is not a leak, just a slightly misbalanced cache, which will go away in time when you need memory. To be completely clear: I have rebooted between updatedb and dd. Later I tried
dd without reboot after updatedb, and it gave me some (but not all) memory back,
look:
total: used: free: shared: buffers: cached:
Mem: 525586432 519598080 5988352 0 166608896 159481856
Swap: 542826496 0 542826496
MemTotal: 513268 kB
MemFree: 5848 kB
MemShared: 0 kB
Buffers: 162704 kB
Cached: 155744 kB
Active: 208132 kB
Inact_dirty: 107936 kB
Inact_clean: 2380 kB
Inact_target: 51840 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 513268 kB
LowFree: 5848 kB
SwapTotal: 530104 kB
SwapFree: 530104 kB
It seems that you are right - it's a greedy inode cache. Welcome me to the
wonderful world of kernel 2.4. :)
Just of a curiosity: how can I see how much memory the inode cache occupies?
You can't see right now. We're working on improving the cache-balance and newer kernels seem to be better so far. I'll mark this bug as RFE (request for enhancement) OK, thanks. Tune the cache as needed, and could you please also make the inode cache size visible somehow? An extra line in /proc/meminfo would be perfect. |
I boot my PC with stock Red at 7.1 installed and in a short time updatedb is run by anacron. When it ends, this is how /proc/meminfo looks like: total: used: free: shared: buffers: cached: Mem: 525586432 519958528 5627904 0 161689600 68882432 Swap: 542826496 0 542826496 MemTotal: 513268 kB MemFree: 5496 kB MemShared: 0 kB Buffers: 157900 kB Cached: 67268 kB Active: 164436 kB Inact_dirty: 58032 kB Inact_clean: 2700 kB Inact_target: 196 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 513268 kB LowFree: 5496 kB SwapTotal: 530104 kB SwapFree: 530104 kB I am missing about 200 MB of RAM, and no process is using it (checked with top). I think that updatedb triggers some bug in kernel which causes this massive memory leak. I have three FAT32 partitions mounted, which are indexed by updatedb, so maybe the problem is in there...