gam_server CPU eater is back

[Sylvain Rouillard]

Hi Daniel,

That's true, I wasn't very specific, the main aim of my mail was to know if it 
was a problem at my end, or if it was a problem that was observed by many 
others.

Actually, after I posted this mail, I decided to kill gam_server, like in the 
good old days, to see what it does. Well, this seemingly fixed the problem 
for a bit. Now that I look closer, gam_server seems to be using the CPU by 
growing waves, so to speak. It's peaking at 10% now, I'll see if peaks keep 
going up. My system has been up for 4 days now without a reboot, so, if my 
observation is confirmed, it could very well explain how it ended up peaking 
at 100% after 4 days.

>From my perspective, I do not see how resource changes could lead to such a 
behavior (growing peaks over time), but then again, I could be completely 
off, hence my poll for other's input on that. I can also not understand how 
killing the service would fix that 'problem' if it is only related to 
resources changes (which rate was presumably unchanged by the murder of that 
poor gam_server). But then again, this may very well be due to my own 
ignorance.

I'll keep watching what gam_server does anyway :-)

Le Mardi 3 Mai 2005 14:19, Daniel Veillard a écrit :
> On Tue, May 03, 2005 at 01:30:24PM +0200, Sylvain Rouillard wrote:
> > Am I the only one to see this?
> >
> > I've had the problem with gam_server eating 100% of my CPU with FC3, and
> > it looks like the problem is back now in FC4T2. I cannot tell since when
> > though. But very often (several times per minute I'd say), I see my CPU
> > usage going up to 100%, due to gam_server, staying up there for a few
> > seconds and going back to normal.
>
>   sounds potentially normal. One of the program asked to watch a
> resource which is constantly changing. After a while gam_server detects the
> flood of event and switch back to polling. Don't ask for kernel monitoring
> of resources which change constantly, the kernel will just by default send
> you a continuous stream of change notification events. If it's a different
> scenario, then nothing in your mail allowed to guess what it might be.
>
> Daniel
>
> --
> Daniel Veillard      | Red Hat Desktop team http://redhat.com/
> veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
> http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/