Bug 124361
Summary: | fam hogs cpu | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Stephen Zobell <szobell> |
Component: | fam | Assignee: | Daniel Veillard <veillard> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2 | CC: | alpha_zorro, bugs.michael, jean-marc.valin |
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: | 2004-08-24 11:57:05 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: |
Description
Stephen Zobell
2004-05-25 22:40:26 UTC
I have another example, in case my first example looks unrealistic. Create a directory and put 1000 files in it: mkdir /tmp/tmptst cd /tmp/tmptst c=1; while [ $c -lt 1000 ]; do c=`expr $c + 1`; ls > f$c; done This processing is very slow, with nautilus using 50%, fam 12%, X 25%, metacity 5%, bash < 1% of the CPU. This may be similar to expanding a tar archive. I think slowing down fam using priorities will help here since it appears nautilus is trying to keep up with fam. Next, create a large tar file: tar czf tmp.tar.gz ~ Now fam uses 80%, gzip 15%, nautilus 2%. When nautilus is dismissed, gzip jumps to 90%. So a tar that should take 10 minutes will take 60 minutes if I happen to be looking at the directory in nautilus! I think this is a reasonable scenario. I have directories with a thousand files. Lowering the priority of fam is one thing that can be done now, and low priority will not stop fam from running altogether. But proiroty is not a complete solution, fam should restrain itself. The user may decide to nice the tar process (or mencoder or whatever they are doing) and we are back where we started with fam hogging the cpu. *** Bug 124636 has been marked as a duplicate of this bug. *** *** Bug 126815 has been marked as a duplicate of this bug. *** The bug report I made (124636) has been marked as a dupe, but I'd just like to point out that in my case, fam ended up using 50% CPU, even though neither nautilus or konqueror (or any other file manager) had a window open in the directory where the file was being written. For bug 124636 (Jean-Marc Valin) do we know who is causing fam to execute? In my tests fam would quit if nobody was asking for the service (like nautilus). There must be some hidden process requesting the service. Also, would lowering fam priority (adding "nice = 19" to /etc/xinetd.d/sgi_fam) help out? I was afraid to just turn fam off, since somebody may depend on it. I also put a bug report into the fam developers when I created this report. Bug 331: http://oss.sgi.com/bugzilla/show_bug.cgi?id=331 For bug 124636, I think it's probably the KDE desktop or something that talks to fam, even though I didn't have any file manager window opened. Even if I had a windows open (e.g. for my home directory), it's still unacceptable that fam eats that much CPU for a directory that's not even being watched. Heavy fam CPU usage is unacceptable whether you are looking at the directory listing or not! But fam hogging the CPU when you are not looking at the directory is also disturbing. Is it possible the directory you were writing to is in your path? It seems bash is quickly aware of executable files installed or added to directories in the path. I wonder if fam is the mechanism used to find out about these new files. No, the directory wasn't even in my path. In case it makes any difference (I don't think it does), my shell is zsh. One other thing, the problem was happening when running ./myprogram > logfile and the amount of CPU taken by fam was directly related to the amount of stuff my program was printing. I will get this fixed I hope but not as part of fam. fam is being obsoleted by gamin in FC3, and I'm adding some rate control processing in gamin. Basically if a monitored resource is too busy, gamin will desactivate dnotify (i.e. kernel monitoring) and switch back to a polling based mode for that resource until things slow down. In that mode the resource is checked every seconds and appropriate events will then be generated. Then if the resource stops generating events for 10 seconds it will be switched back to kernel monitoring to avoid polling. This is implemented in gamin CVS, but not yet released, this should make it to rawhide sometime this week. Daniel gamin-0.0.7-1 has been pushed to Rawhide, it should show up in fedora development within a day and will hopefully fix this problem, Daniel |