CPU going to 100% a lot - Leap 42.3

English Hardware
1

Hello:

Here are my hardware specs:
OpenSuse Leap 42.3 64 bit KDE on a HP Pavilion i7 OctoCore notebook with 12g RAM for business/personal use (Not a server).

I installed the OS yesterday on a fresh system as a single boot OpenSuse.
First thing was to add the Pacman and Main repositories and completely update the system.

Right away I noticed it was very sluggish for the first few minutes after boot and I put the CPU load monitor, Memory Status and HD I/O monitor widgets on the desktop.
I’ve noticed the Memory and HD status seem to be reasonable at that time, but all 8 cores (One or two may drop off to ~80% at times) of my CPU load. Then, after 2-4 minutes they would settle back down to normal levels.

I do a lot of 3D graphical work so I installed quite a few programs from the official repositories. Blender, KdenLive, AudioJack, Gprename, Wine with a few necessary .exe programs installed.

I am sitting down to begin some work in Blender and noticed my system periodically slowing down to ridiculous levels. For example I open Kate to type a note and Kate takes a few minutes to open.

I noticed all 8 CPU cores are slammed at 100% on the widget, cooling fan on high blowing hot air, Memory usage is a cool 400-800mb and the HDD is at reasonable levels. They typically stay at 100% for a few minutes then slowly make their way back down to normal levels the go back to 100% after a few minutes as this slow-down cycle continues.

I looked around the web and discovered a command to monitor processes and this was recorded when 8 cores were 100%:

me@linux-x79b:~> top -n 1
Tasks: 257 total, 5 running, 251 sleeping, 0 stopped, 1 zombie
%Cpu(s): 36.6 us, 2.0 sy, 0.7 ni, 35.1 id, 25.5 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 12189600 total, 4382684 used, 7806916 free, 2868 buffers
KiB Swap: 2106364 total, 0 used, 2106364 free. 3310232 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
** 6283 root 20 0 119116 97368 2072 R 93.75 0.799 0:06.11 systemd-coredum
6302 root 20 0 118984 97560 2080 R 93.75 0.800 0:03.11 systemd-coredum
6303 root 20 0 118984 97304 2020 R 93.75 0.798 0:02.17 systemd-coredum
6322 root 20 0 118984 21928 2020 R 56.25 0.180 0:00.22 systemd-coredum **
6305 me 39 19 646264 26484 16672 D 12.50 0.217 0:00.20 tracker-extract
6324 root 20 0 23736 2128 1900 D 12.50 0.017 0:00.02 systemd-coredum
6321 me 39 19 0 0 0 Z 6.250 0.000 0:00.13 single
1 root 20 0 185020 5684 3996 S 0.000 0.047 0:03.67 systemd
2 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.000 0.000 0:00.02 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.000 0.000 0:00.62 kworker/u16:0
7 root 20 0 0 0 0 S 0.000 0.000 0:00.58 rcu_sched
8 root 20 0 0 0 0 S 0.000 0.000 0:00.00 rcu_bh
9 root rt 0 0 0 0 S 0.000 0.000 0:01.13 migration/0
10 root rt 0 0 0 0 S 0.000 0.000 0:00.00 watchdog/0
11 root rt 0 0 0 0 S 0.000 0.000 0:00.00 watchdog/1
12 root rt 0 0 0 0 S 0.000 0.000 0:01.13 migration/1
13 root 20 0 0 0 0 S 0.000 0.000 0:00.02 ksoftirqd/1
14 root 20 0 0 0 0 S 0.000 0.000 0:00.08 kworker/1:0
15 root 0 -20 0 0 0 S 0.000 0.000 0:00.00 kworker/1:0H
16 root rt 0 0 0 0 S 0.000 0.000 0:00.00 watchdog/2
17 root rt 0 0 0 0 S 0.000 0.000 0:01.13 migration/2
me@linux-x79b:~>

The 100% usage seems to be associated with the core dumps listed above…
I am hoping someone can point me in the right direction to resolve this.
Thanks in advance,
-Steve

2

if this is your first time using KDE, then its most likely the indexing at work (akonadi). You can test this by stopping akonadi temporarily, see if the CPU drops down to an acceptable level. Then restart akonadi. Depending on the size of your drive indexing may take a little bit of time or an hour or more, then CPU will be much less.

Ref: https://forum.kde.org/viewtopic.php?t=138239
https://userbase.kde.org/Akonadi/en

Edit, I reread your post and noticed your mentioned core-dumps…on Gnome this can happen with tracker, so this points to akonadi and nepumuk/baloo as well.
Ref: https://userbase.kde.org/Nepomuk

3

Thank you very much for the reply ChuangTzu.

I really needed to get up and running ASAP so i booted the install disk and ran the Suse install.

I was very pleasantly surprised to find all my user files still intact upon reboot. Also my cores running at a low load.

I’m in the process of a system update and i believe it will be Ok.
I’ll have to monitor the programs i install more closely and determine what caused the condition should it happen again. As well as akonadi indexing.

I appreciate the helpfulness of this community.
-Steve

4

Indexing is done by baloo though, not akonadi.
You can disable it in KDE’s settings, “Desktop Search”.

But the CPU load here is caused by systemd-coredump (it is generating coredumps of crashed processes), as you note:

Edit, I reread your post and noticed your mentioned core-dumps…on Gnome this can happen with tracker, so this points to akonadi and nepumuk/baloo as well.
Ref: Nepomuk - KDE UserBase Wiki

No, it doesn’t.

First, Nepomuk doesn’t exist any more since years.
And just because there is a problem with tracker likely crashing currently, that doesn’t mean that it affects baloo or akonadi too.

Run coredumpctl to show a list of the crashes.

But it likely is tracker, I suppose. It will be started when logging in to KDE too if it is installed.
And the output of “top” in the first post does list “tracker-extract”.

My recommendation: uninstall tracker, especially if you use a KDE desktop…
But if you did a fresh KDE installation, it shouldn’t get installed anyway.

Btw, there was another thread recently about the very same problem:
https://forums.opensuse.org/showthread.php/526919-systemd-is-consuming-a-LOT

5

It seems to be associated with using gnome: switch to other desktops like enlightement: and the problem resolves itself

6

Hi
No, a bug in tracker-extract: 1017652 – tracker-extract process generating core dumps through udev bad system call to socket()

For me it was associated with softlinks. Redefining the search directories and resetting the indexing with;


tracker reset --hard