TOP consumes 100% CPU

westand · #1 24th November 2011, 05:07 AM

My fan is working pretty hard when the computer is idle-ish (and running hot). So I run "top" to see what is going on, and it shows that "top" has 100% utilization. Never seen this before. Also doesn't give me the greatest idea what is going on. How should I troubleshoot each of these issues: (a) top being stupid even though the delay is set to 3 seconds, and (b) the larger issue of the fan always being on.

JEO · #2 24th November 2011, 07:02 AM

I would try booting from various versions of the live cd and see if the problem shows up there. Also if you put more specific information about what type of hardware you have someone might have the same and be able to help.

outsourcededm · #3 24th November 2011, 08:59 AM

i've previously had an issue with FF plugins running away on CPU and mem leaks.. do you have firefox running when PC is 'idleish?'

PatMcLJr · #4 24th November 2011, 02:25 PM

my 2 cents, top works well but htop is what I prefer, you can kill a process on the spot and chose you flavor of killing, I use good old #9

jpollard · #5 24th November 2011, 02:41 PM

You don't indicate which release you are using, but I have found that the named process has a tendency to run away with itself. (right now mine indicates 138% of a CPU - I have 8 cores, so it's impact is not critical)

another one is the gnome e-calendar-factory, as it seems to not terminate when the user logs out. This leaves a growing number of processes though none appear to use the cpu that much... though even killing them all, they keep coming back if somebody is logged in.

Top itself does take a lot of time - but remember, at the time top is taking it's CPU samples, it has to also be running.... which gives it a tendency to catch itself as the top user (right next to X or the terminal session when using a terminal window).

Also top does let you kill processes.

There is a warning about using 9 to kill processes -- yes it will kill it, but it can also cause file corruption if it is something that uses keyed files... I use 15 (SIGTERM) first, which allows the process at least a chance to close things out flushing buffers, but if it doesn't work, then a 9 (SIGKILL) which cannot be caught.

PatMcLJr · #6 24th November 2011, 03:02 PM

Thanks for the tip, I'll switch over to that.