Bug 151507

Note: if I set gam_server to debug mode per
http://www.gnome.org/~veillard/gamin/debug.html#Debugging1 , the high CPU load
can not be reproduced.  Without sending the SIGUSR2, it always happens here.

My FC4test1 box (2.6.11-1.1177_FC4smp) has extremely high CPU load on all sorts
of high network load. I tested http, ssh, ftp. It gets about 6 MB / s on the LAN
with the ftp/wget/scp process at 99% CPU. Might be the same problem.

I observe this downloading to a user home directory.

I'm running KDE as a window manager, xmms, several xterms, xchat and firefox. 
No gui file managers or anything that might be querying the gam_server about the
file.

Downloading over a 3Mbit/sec DSL link, the gam_server goes to 99% CPU on a 2GHz box.

My box is running FC3 with gamin-0.0.25-1.FC3.

Fix is in CVS, I need to release and package it,

Daniel

I hit this as well really bad yesterday when downloading the FC4t2 CDs onto my
FC3 system. gam_server was eating so much of the CPU that my system was barely
usable. I was doing the download with ncftp in a gnome-terminal window.

I still don't see an update even in the testing repository. Will this be
released for FC3 as well? Any idea on the time frame?

Thanks for your work on this.

Appears to be fixed for FC4 in gamin-0.1.0-1, leaving open for FC3 update comments.

The problem has resurfaced and is reproducible in gamin-0.1.1-3.FC4.  
Downgrading to 0.1.0-1.1 doesn't help either. 

No idea. There are regression tests in gamin to check for correct handling
of flood. I can't understand how downgrading backt o the "good" version would
not fix this. There is something fishy with your environment.
You need to do the following steps:

   1/ download a tar.gz of the latest version, expand, run configure, make,
      and make tests, report back any error on make tests
      http://www.gnome.org/~veillard/gamin/downloads.html

   2/ make sure you upgraded to the latest testing release (0.1.3), 
      delog, kill all gam_server, relog, swicth gam_server to debug
      by sending it an USR2 signal
      http://www.gnome.org/~veillard/gamin/debug.html#Debugging1
      reproduce your problem
      resend an USR2 signal
      read the log left in /tmp for obvious problem, if nothing obvious
      attach it to this bug.

Daniel

Some more info:   
   
The gam_server process no longer takes _all_ available CPU, but a lot of it   
nevertheless.  Typical values from "top" witnessed during a scp to my home dir  
over a 11Mb/s WLAN (throughput around 700kB/s) on a P3 laptop:   
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 
 3304 scop      15   0  2744 1540  872 S 51.2  0.6   0:21.97 gam_server   
 3759 scop      15   0  4604 2452 1636 S 12.8  1.0   0:02.06 ssh   
   
I took the 0.1.3 package from devel CVS, ran "rpm -bi" on it on FC4, cd'd to 
the build dir and ran "make check": no errors or warnings on the console.  But 
the high load is still present in 0.1.3 built from devel CVS (still on FC4, no 
devel system to test with). 
  
Note also that I reported this being fixed earlier in 0.1.0-1, but stated that  
downgrading to 0.1.0-1.1 does not help.  I can't find 0.1.0-1 anywhere to test  
with, but at least the specfile change between -1 and -1.1 doesn't look like 
one that could make any difference wrt this.  
 
I'll try debugging later if you think the ~50% CPU usage above isn't expected, 
but to clarify: by delog/relog you mean logout/login? 

> The gam_server process no longer takes _all_ available CPU, but a lot of it   
> nevertheless.

  okay, answer is "wait for a kernel with inotify", things should be better then.
But you can still look at the debug output to get a better understanding of what
is going on in your case.

> by delog/relog you mean logout/login? 

  yes, make sure gam_server and clients are restarted from scratch.

Daniel

Created attachment 117510 [details]
debug output - 0.1.3-1, high load, 100% load afterwards

Well, there's certainly something else happening.

With 0.1.1-3.FC4, after a fresh KDE login, scp'ing a 100MB file over the above
connection always presents the high load.  But if I do the USR2 thing to grab
debug output, the high load never seems to happen, so I cannot get a log of it.


With 0.1.3-1, the exactly same operation does not _always_ result in the high
load, but it sometimes does.  Additionally, sometimes after the download
completes, gam_server continues to consume 100% CPU.  With this version, I
managed to get logfiles from two times when the high load happened.  The
attached log is from such a case: 0.1.3-1, high load during download, 100%
gam_server CPU usage after download completed.

Created attachment 117511 [details]
debug output - 0.1.3-1, high load, 0% CPU usage afterwards

Here's the other case: 0.1.3-1, high load during download, 0%
gam_server CPU usage after download completed.

One more bit of info: I've managed to reproduce the problem only when logged   
into KDE.  When logged into GNOME, both 0.1.1-3.FC4 and 0.1.3-1 have behaved 
as expected, with barely noticeable CPU usage during the download, and no 
hangs afterwards. 

I too experience this problem.  Noticed it this morning when downloading a 75MB
file from IRC (irssi) with KDE.

What exactly is gamin?  Do I really need it on my system?  This cpu load is
kinda annoying and I'd like to know if I could just remove this package without
harming anything.

I no longer get this bug with gamin-0.1.7-1.2.1 on FC5.

Also see bug 196444.  A few people seem to mention KDE and NFS as possibly being
required to hit these bugs.  It seems to pop up for me when I start using
konqueror, which I use as a file browser under gnome since I like it better. 
Perhaps there is some buggy interplay between gamin/gnome/kde (and maybe NFS!).
 If you haven't seen this bug, try leaving konqueror open browsed to a NFS mount
(like file:/mnt/nfsmount/foobar).  I'm pretty sure that should do it (high CPU
or memleak) for anyone.

Closing since FC4 is no longer supported, and comment 15 indicates that it has
been fixed in FC5 and later.