Red Hat Bugzilla – Bug 151507
gam_server consumes lot of CPU during large file copy
Last modified: 2007-11-30 17:11:02 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.
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
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,
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
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.
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:
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
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.
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
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
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.