Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ksoftirqd and several userspace apps hogging CPU

111 views
Skip to first unread message

Blumf

unread,
Aug 1, 2012, 11:25:42 AM8/1/12
to
Recently my system (Slack64 13.37) seems to be spinning its wheels.

Check this example from top:

PID USER %CPU %MEM TIME+ COMMAND
18671 scott 95 3.0 1534:23 firefox
12606 scott 53 1.7 1639:36 thunderbird-bin
3 root 16 0.0 1722:03 ksoftirqd/0
13 root 14 0.0 1564:45 ksoftirqd/2
9 root 14 0.0 1707:23 ksoftirqd/1
4307 scott 3 0.2 141:31.75 audacious2

What's going on? I can't figure out what the best course of action is to
diagnose this.

Blumf

Henrik Carlqvist

unread,
Aug 1, 2012, 3:17:03 PM8/1/12
to
If you only want to know which app is causing this you could start to kill
those apps using the most CPU and see if it helps, something like:

killall firefox
killall thunderdbird-bin

or

kill 18671
kill 12606

If you want to dig deeper into this you might get some clue from the
output from strace:

strace -p 18671

However, strace usually gives a lot of output. It does not show heavy CPU
usage like calculations, but system calls like opening files and stuff
like that.

The next step would be to recompile the hogging application with the -g
switch to gcc and then run it in a debugger like gdb or, maybe more
userfriendly interface, ddd. Valgrind with --tool=callgrind together with
kcachegrind is also useful to see were applications spend their CPU
cycles, but again, this requires that the application was compiled with
the -g switch.

I don't have much ideas for those ksoftirq processes. Maybe it could be
that it is your CPU that has become slow rather than the processes
demanding more CPU power? Check with dmesg if you see any odd messages
like CPU cache disabled or anything else that would explain a slower CPU.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

D Herring

unread,
Aug 1, 2012, 9:19:07 PM8/1/12
to
Sounds like animated (flash) advertisements, probably with sound too.
May also be heavy javascript. Did you upgrade any software recently?

- Daniel

Blumf

unread,
Aug 2, 2012, 6:42:47 AM8/2/12
to
On 01/08/12 20:17, Henrik Carlqvist wrote:
> Blumf <bl...@hotSPAMmail.com> wrote:
>> Recently my system (Slack64 13.37) seems to be spinning its wheels.
>>
>> Check this example from top:
>>
>> PID USER %CPU %MEM TIME+ COMMAND
>> 18671 scott 95 3.0 1534:23 firefox
>> 12606 scott 53 1.7 1639:36 thunderbird-bin
>> 3 root 16 0.0 1722:03 ksoftirqd/0
>> 13 root 14 0.0 1564:45 ksoftirqd/2
>> 9 root 14 0.0 1707:23 ksoftirqd/1
>> 4307 scott 3 0.2 141:31.75 audacious2
>>
>> What's going on? I can't figure out what the best course of action is to
>> diagnose this.
>
> If you want to dig deeper into this you might get some clue from the
> output from strace:
>
> strace -p 18671
>
> However, strace usually gives a lot of output. It does not show heavy CPU
> usage like calculations, but system calls like opening files and stuff
> like that.

Now that's interesting, when I attach and detach strace to firefox and
thunderbird, they calm down and no longer hog the CPU.

I think this may be down to qbittorrent (which wasn't present in the
example as I had killed it already), that's taking up ~150% (3 core
chip). strace on that is showing mostly futex calls, constantly. e.g.:

futex(0xcfd768, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xcfd76c, FUTEX_WAIT_PRIVATE, 212720197, NULL) = -1 EAGAIN
(Resource temporarily unavailable)


> The next step would be to recompile the hogging application with the -g
> switch to gcc and then run it in a debugger like gdb or, maybe more
> userfriendly interface, ddd. Valgrind with --tool=callgrind together with
> kcachegrind is also useful to see were applications spend their CPU
> cycles, but again, this requires that the application was compiled with
> the -g switch.

I'll have a fiddle with this, but qbittorrent was working okay
originally. I have a feeling something is wrong with an update I've
applied elsewhere, been having nothing but trouble with Slack 13.37 from
day one so I may end up just nuking the install as soon as 14.0 comes
out (soon I hope).


> I don't have much ideas for those ksoftirq processes. Maybe it could be
> that it is your CPU that has become slow rather than the processes
> demanding more CPU power? Check with dmesg if you see any odd messages
> like CPU cache disabled or anything else that would explain a slower CPU.

Yeah, I get the feeling that they're a symptom of stuff being overloaded
rather than a cause.

Blumf

Petri Kaukasoina

unread,
Aug 2, 2012, 7:11:36 AM8/2/12
to
Blumf <bl...@hotSPAMmail.com> wrote:
>
>futex(0xcfd768, FUTEX_WAKE_PRIVATE, 1) = 1
>futex(0xcfd76c, FUTEX_WAIT_PRIVATE, 212720197, NULL) = -1 EAGAIN
>(Resource temporarily unavailable)

I guess you are using ntpd and have hit the leap second bug.

Blumf

unread,
Aug 2, 2012, 8:37:12 AM8/2/12
to
Been having the problem since before June 30, so I doubt that's the
cause. I'm wondering if it's a kernel update and, possibly, an issue
with ReiserFS[0].

(FWIW, using chrony, and enjoyed seeing 23:59:60 :) )

[0] Might take a risk and move /home onto Btrfs when Slack14 comes
around. Haven't seen a good discussion of file systems lately.

John F. Morse

unread,
Aug 2, 2012, 2:24:07 PM8/2/12
to
I use reiserfs on many boxen and have never had any file system issues.

--
John

When a person has -- whether they knew it or not -- already
rejected the Truth, by what means do they discern a lie?
0 new messages