Summary: | updatedb does not release memory properly (according to free) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | hodak |
Component: | [OLD] Core system | Assignee: | x86-kernel (DEPRECATED) <x86-kernel> |
Status: | VERIFIED INVALID | ||
Severity: | major | CC: | steel300, tom |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | memory usage and slabinfo before and after updatdb run (incl. tail /dev/zero) |
Description
hodak
2004-01-20 21:48:49 UTC
Can you see if this happens with 2.4.22-ck*? Does your system ever run completely out of memory? No, my system never run out of memory because of this. As I wrote above, running updatedb second, third etc time causes only small (~10MB) or no increase in used memory, so after a few days my memory stabilizes at about 90% used (which seems too much to me, since I run xfce4, and use mostly firebird and xterm). Normally, my memory usage used to be about 50% (I run gkrellm ). But then again, since discovering the bug my maximum uptime was about a week, mostly due to frequent updates of gentoo-sources. I have not tried ck sources, I did try vanilla sources 2.4.22 and had the same problem. Is there a reason why ck source should behave better? If there is I will try them out. Just tried 2.4.23-ck1 (latest stable ck kernel), it shows the same beahviour. Here is what free shows after reboot and updatedb # free -m total used free shared buffers cached Mem: 503 497 5 0 203 14 -/+ buffers/cache: 280 223 Swap: 980 0 9 Reemerging mplayer increases memory usage by 2MB (which is negligible). My findings are as follows: With gentoo sources and aa sources 2.4.22 and 2.4.23, memory is not released visually after running updatedb. In both cases it runs memory almost to my max (1gb) after which both gkrellm memory monitor and free report almost all memory used. My machine behaves more slowly and erratic afterward until I reboot. I did a world update recently which included kde/gnome/gcc etc, but this problem has been happening since I switched to 2.4.22. I went back to 2.4.20-gentoo-r7 kernel, and although I had to turn off high memory and acpi, I find some more strangeness. After running updatedb, within 30 min, all memory as reported by gkrellm is released back to what it should be, however the free command still reports all memory used, even 15 hrs after running updatedb. I don't know where the blame for this lies, but I suspect with several things. Oddly enough I never got any out of memory errors even when attempting to run programs after updatedb when using 2.4.22+ kernels. This just is not right. It makes memory monitoring useless. i'm having the same problem with 2.4.22-gentoo-r5 and reiserfs on the / partition. $ uname -a Linux GEN2 2.4.22-gentoo-r5 #1 Thu Jan 15 21:30:08 CET 2004 i686 AMD Athlon(tm) processor AuthenticAMD GNU/Linux $ grep "hda3" /etc/fstab /dev/hda3 / reiserfs noatime 0 0 $ free -m total used free shared buffers cached Mem: 756 108 647 0 6 47 -/+ buffers/cache: 55 700 Swap: 517 0 517 $ updatedb $ free -m total used free shared buffers cached Mem: 756 714 41 0 326 51 -/+ buffers/cache: 335 420 Swap: 517 0 517 $ ooffice $ free -m total used free shared buffers cached Mem: 756 735 20 0 288 108 -/+ buffers/cache: 338 417 Swap: 517 0 517 I'm going to take this upstream to LKML. For anyone looking at this bug, there is more info on bug 36855, although it isn't specifically related. I'm seeing the same sort of behavior on my 2.6.1 development-sources system, so I don't think this is just a 2.4 problem... I you people sure what you are seeing is not inode cache chewing lots of memory which should be natural when updatedb lookups lots of files? The fact that OOM never happens on those systems (in normal conditions) only implies that the inode cache is still freed when system needs the memory. Also looking in /proc/slabinfo before and after first updatedb run and looking at the amount of free memory after updatedb, and then after "tail /dev/zero" run (which is going to consume all the memory it can get) will show if the memory is actually was freed. The 2.6 problem where inode cache was not freed aggressively enough was also recently fixed (I do not remember if it was also visible in 2.4) I guess if this is not supposed to be a problem we should enter bugs for all the popular memory applications since the definition of "free" memory has been changed. Created attachment 25523 [details]
memory usage and slabinfo before and after updatdb run (incl. tail /dev/zero)
I am attaching data on memory usage, slabinfo before and after updatedb and
also after "tail /dev/zero" (which takes a lot of memory). The complete data is
in the attachment, so I will only shortly summarize it here.
I did it on freshly rebooted system.
Used memory: 22M
Slabinfo shows:
inode_cache 7016 7021 512 1003 1003 1
dentry_cache 7974 7980 128 266 266 1
Run updatedb
Used memory: 302M
Slabinfo:
inode_cache 392608 392616 512 56088 56088 1
dentry_cache 395025 395040 128 13168 13168 1
Now tail /dev/zero, which tries to use all available memory and swap. The
process is killed automatically after a minute or so.
Used memory: 9M
Slabinfo:
inode_cache 209 511 512 73 73 1
dentry_cache 191 1200 128 40 40 1
I do not understand slabinfo entries very well, so I am not sure if I can
interpret the reults correctly, but since memory taken by updatedb can be used
if necessary, updatedb does not leak memory. But then it means that free does
not report memory usage properly and then a bug report with respect to free
should be filed.
At least that is my understanding.
Free reports memory as the kernel sees it. After a program finishes executions, its memory isn't given back immediately. Free reports this like it should. Instead, the memory it was using just sits there waiting to be overwritten. Since the pages were never actually cleared, free won't report them as being available. In all actuality, those pages are ready for other programs to use. GKrellm, or similar, is more accurate with respect to how much memory you have available. There is no need to have a mad rush when a program exits to free all of it's pages. Memory is there to be used, why not use it? Closing. Never really was an issue. Closing. |