Red Hat Bugzilla – Bug 124361
fam hogs cpu
Last modified: 2007-11-30 17:10:43 EST
Description of problem:
FAM uses too much CPU and its priority is too high. If a file browser
like nautilus is viewing a directory where files are being updated,
fam can use a huge percentage of the CPU. A process trying to write a
file may end up with only 5% of the CPU.
Steps to Reproduce:
Set nautilus to view a directory, and execute this command to simulate
a program writing files:
ls ~ > tmptmp; cat < tmptmp >> tmptmp
In top, fam used 75% of the CPU, nautilus 19%, and cat 4%.
95% of the machine should not be taken away so I can see thousands of
nautilus updates every second!
Until fam is modified to restrain itself, I suggest adding "nice = 19"
I have another example, in case my first example looks unrealistic.
Create a directory and put 1000 files in it:
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
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
This is implemented in gamin CVS, but not yet released, this should
make it to rawhide sometime this week.
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