Bug 124361 - fam hogs cpu
fam hogs cpu
Product: Fedora
Classification: Fedora
Component: fam (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Veillard
: 124636 126815 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-05-25 18:40 EDT by Stephen Zobell
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-24 07:57:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stephen Zobell 2004-05-25 18:40:26 EDT
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.

How reproducible:


Steps to Reproduce:
Set nautilus to view a directory, and execute this command to simulate
a program writing files:

ls ~ > tmptmp; cat < tmptmp >> tmptmp
Actual results:

In top, fam used 75% of the CPU, nautilus 19%, and cat 4%.

Expected results:

95% of the machine should not be taken away so I can see thousands of
nautilus updates every second!

Additional info:

Until fam is modified to restrain itself, I suggest adding "nice = 19"
to /etc/xinetd.d/sgi_fam.
Comment 1 Stephen Zobell 2004-05-27 16:50:28 EDT
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.

Comment 2 Michael Schwendt 2004-07-12 14:57:13 EDT
*** Bug 124636 has been marked as a duplicate of this bug. ***
Comment 3 Michael Schwendt 2004-07-12 14:57:42 EDT
*** Bug 126815 has been marked as a duplicate of this bug. ***
Comment 4 Jean-Marc Valin 2004-07-12 15:33:27 EDT
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.
Comment 5 Stephen Zobell 2004-07-13 11:27:28 EDT
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.
Comment 6 Stephen Zobell 2004-07-13 11:37:50 EDT
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
Comment 7 Jean-Marc Valin 2004-07-13 14:58:16 EDT
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.
Comment 8 Stephen Zobell 2004-07-13 16:49:06 EDT
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.
Comment 9 Jean-Marc Valin 2004-07-13 17:40:02 EDT
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.
Comment 10 Daniel Veillard 2004-08-24 06:38:59 EDT
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.

Comment 11 Daniel Veillard 2004-08-24 07:57:05 EDT
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


Note You need to log in before you can comment on or make changes to this bug.