Bug 151507 - gam_server consumes lot of CPU during large file copy
gam_server consumes lot of CPU during large file copy
Product: Fedora
Classification: Fedora
Component: gamin (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
Depends On:
  Show dependency treegraph
Reported: 2005-03-18 14:48 EST by Ville Skyttä
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version: gamin-0.1.7-1.2.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-27 00:56:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
debug output - 0.1.3-1, high load, 100% load afterwards (1.29 MB, text/plain)
2005-08-06 09:41 EDT, Ville Skyttä
no flags Details
debug output - 0.1.3-1, high load, 0% CPU usage afterwards (2.93 MB, text/plain)
2005-08-06 09:45 EDT, Ville Skyttä
no flags Details

  None (edit)
Description Ville Skyttä 2005-03-18 14:48:15 EST
Bug 132354 noted, this didn't smell like a duplicate so opened a new one:

During downloading or copying big files to my home dir, gam_server takes grabs
all available CPU.  After the download/cp finishes, gam_server calms down too to
normal CPU load readings (ie. nonexistent).

Reproduced on 2 boxes: one FC3, one FC4test1, both running gamin-0.0.26-1, by
downloading Rawhide kernel rpms over HTTP (at some 700kB/sec) with wget, and by
copying some ISO images to my home dir over from a local disk.
Comment 1 Ville Skyttä 2005-03-18 15:18:07 EST
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.
Comment 2 Ralf Kleineisel 2005-03-21 06:08:53 EST
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.
Comment 3 Mark Frazer 2005-03-31 08:33:58 EST
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

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.
Comment 4 Daniel Veillard 2005-03-31 09:15:31 EST
Fix is in CVS, I need to release and package it,

Comment 5 Steve Fox 2005-04-12 15:22:45 EDT
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.
Comment 6 Ville Skyttä 2005-05-30 14:46:07 EDT
Appears to be fixed for FC4 in gamin-0.1.0-1, leaving open for FC3 update comments.
Comment 7 Ville Skyttä 2005-08-05 07:21:58 EDT
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. 
Comment 8 Daniel Veillard 2005-08-05 08:01:04 EDT
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

   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
      reproduce your problem
      resend an USR2 signal
      read the log left in /tmp for obvious problem, if nothing obvious
      attach it to this bug.

Comment 9 Ville Skyttä 2005-08-05 09:33:56 EDT
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@1.13GHz laptop:   
 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? 
Comment 10 Daniel Veillard 2005-08-05 09:44:00 EDT
> 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.

Comment 11 Ville Skyttä 2005-08-06 09:41:46 EDT
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.
Comment 12 Ville Skyttä 2005-08-06 09:45:01 EDT
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.
Comment 13 Ville Skyttä 2005-08-06 09:52:59 EDT
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. 
Comment 14 Christopher Stone 2006-03-02 07:54:58 EST
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.
Comment 15 Christopher Stone 2006-04-03 00:34:14 EDT
I no longer get this bug with gamin-0.1.7-1.2.1 on FC5.
Comment 16 Trevor Cordes 2006-07-18 14:37:53 EDT
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.
Comment 17 Matthias Clasen 2006-11-27 00:56:03 EST
Closing since FC4 is no longer supported, and comment 15 indicates that it has
been fixed in FC5 and later.

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