Bugzilla – Bug 155340
HTDIG takes up 90% of CPU
Last modified: 2006-03-21 15:33:09 UTC
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8361 root 27 10 35484 23m 1852 R 91.3 9.6 3:27.74 htdig I filed this as a bug (mixed in with the y2base problem)...but it really didn't get much attention...because it went towards the yast issue. Anyway, this was very random, but I noticed things were running slow again, checked top...and as you can see above, htdig is taking up 90% of my cpu. I'm not sure which log you need...but I figured I should file this as a bug so it is ironed out before the final release.
Joe, we can handle only one problem per report, so always file seperate reports for seperate problems. Is there any way to reproduce this reliably? What makes you sure this is a bug? Please be more verbose.
*** Bug 155330 has been marked as a duplicate of this bug. ***
Duplicate of bug #152273?
This was fixed for Beta4, however it could be connected. Joe: When exactly does this happen and how often?
Well it's only happened once so far, which is different than beta 4. I haven't had the problem again after killing the process. If it happens again, is there a certain log I should attach? Thanks
If it happened right after the installation or in connection with susehelp, it could really be the problem in 152273. Is it possible for you to reproduce this (maby with a fresh installation or by deleting the index of susehelp and calling it again)?
I noticed that htdig seems to use extensive algorithms that consumes a lot of CPU-time, it even makes the machine unresponsive for some seconds for a remote connection. So I suppose this is not a bug. Reassigning to Hendrik for a comment.
everything can run with a CPU usage of 100% if its needed. Thats no bug. Will what did you fix in beta4?
If some newbie tries out linux and immediatly notices that one single process is taking up 100% of their CPU, chances are they will conclude that linux sucks and windows is better. This may not be a bug, but it is a problematic feature that will annoy users. However, since I killed it, it has not come back and I've been unable to recreate the issue.
will?
Yes, it's me. Since beta4 I have reduced the number of manuals that susehelp indexes on SuSEconfig run by default. Once an index is generated, susehelp does not reindex on subsequent runs of SuSEconfig.
so i consider this fixed