After login one CPU core is running wit 100% CPU usage but doesn't show the process in htop?

English Install/Boot/Login
,
1

Hello!

SInce the update to plasma 6 I have run into an issue that I can’t figure out…

After login into a KDE Plasma 6 (latest Tumbleweed - all updates) my system starts freezing periodically. Starting any application randomly takes about 30 seconds - sometimes it works normal.

This even applies to Konsole commands…

Now in htop I can see that one of my twelve cores is peaking up to 100% CPU usage for a few seconds then switches to another core immediately - running this one at or clos to 100% CPU usage.

The process list in htop or in KDE process viewer doesn’t show any process with more than a 5% CPU usage…

So I stopped baloo and any background backup services but nothing helps.

After roughly ten minutes this behaviour stops and te behavious doesn’t seem to reappear during a session.

Somewhere in the forums I read that the KDE bluetooth widget and/or KDEconnect could be buggy atm, so I deactivated both widgets in the system tray.

Now I’ve run out of options it seems - my question is:

How to find out what to do here?

Any ideas or similar experiences?
Can anyone help?

Happy Easter!
jhhh

2

Hi, @jhhh!

I’ve suffered from system freezing, either by 100% CPU or by high % of RAM used, in two cases, as long as I can remember, with previous Plasma versions, not with Plasma6 (yet :wink:):

  • 100% CPU: The culprit was System’s Search database (in System Settings). I don’t remeber if database was corrupted or I had some file with weird name, but I had to delete Search database and disable Search option.
  • High % of RAM used: It was caused by ClamAV (used about 2.5GB of RAM) and not enough RAM (4GB) in a laptop. I had to unistall ClamAV.

Hope this helps.

3

Thanks for your answer @Xuco!

The database for searching is fed by the baloo process - I already disabled it.
And I do not have any antivirus running - just an antivirus filter for mail. No I disblaed that too - sadly, that’s not the remedy…

I keep searching.

Have a good holiday (if you have one)!

Cheers,
jhhh

4

btop has a tree view that’s much better suited to find culprits that spawn/span multiple processes.

First establish the steps required to reproduce the problem, then watch btop, and capture the systemd journal logs from this time period.

5

I’ve had btrfs do this in the past, never managed to figure out what it was doing though, recently I had it happen during snapper’s cleaning cycle. It doesn’t show up in top properly, I suspect because it is in the kernel?

6

You night be right- I have one 9 month old snapshot that fails to be deleted…
at least Yast cannot remove it!

I guess I open another thread for how to remove it…

Thx for the hint!

7

Sigh, I didn’t want to go here for fear of increasing OP’s anxiety but since we’re here I might as well add this is exactly how it was just before my btrfs filesystem imploded due to faulty quota/qgroups (had to disable it to fix the errors from happening again, it was turned on by snapper to keep the snapshot space usage in check).

@jhhh Could you do a btrfs check of the btrfs device/partition from a rescue ISO? It’s probably not an issue with the FS (so nothing to be worried about right now), but just to be certain.

8

Yes I will. But cannot do so right now - but I’ll post the result here.

A quick sudo btrfs scrub showed no errors - so the files are allright.

As I wrote in the other thread about removing a faulty snapshot - I could delete this one now. Now I will observe if the lagging has gone.

And I will do the btrfs check as soon as I find the time.

Thanks for your thoughts!

9

Possibly, scrub tests the data/metadata checksums match but does not verify if the btrfs internals are alright. In my two previous btrfs failures, one due to too many kernel panics and the other due to faulty btrfs quota/qgroups there were no errors reported by scrub but many by check.

10

@ pavinjoseph

Could you tell me how to verify if btrfs or snapper activity is the culprit for the high CPU usage before going into the whole btrfs check routine ?

Thanks for your input!

11

Use btop and filter for “btrfs” and/or use the tree view to see what’s causing the CPU/memory usage spike.

You can also initiate a check on the mounted filesystem but the manpages (man 8 btrfs-check) do not recommend it:

sudo btrfs check --force </path-to-btrfs-dev>
12

Is btrfs quota on / turned off? Since kernel 6.8 this btrfs-check became really annoying again

13

Seems like it is! Though I am pretty sure I never enabled it when setting up the partitions… that is strange…

sudo btrfs qgroup show -p /

gives me about one thousand lines looking like this

0/11854          0.00B        0.00B 1/0        <stale>

Am I correct to assume that these are qutas for long since deleted snapshots?

Don’ these unnecessarily bloat the qgroup management?

Well… , I will try to turn off quotas and see what happens after reboot.

Fingers crossed!

14

@pavinjoseph : - You have been right all along! And @desmond - after I took your advice and disabled btrfs quotas on / …

The result - at least for now - is that the freezing and lagging is gone!

There are no high CPU usage peaks any more at all - my system is running for hours now - and it stays buttery smooth… :slight_smile:

CPU usage while browsing with over 30 tabs including youtube, also akonadi working on a dozen mail accounts oscilates calm and relaxed around 10% - that is really nice for a change!

So thanks a lot - I tip my hat to you!

Happy holidays!
jhhh

2 Likes