Leap 15.6, KDE/Plasma (Wayland) 5.27.11, KDE Frameworks 5.115.0, QT 5.15.12.
After applying latest updates (zypper patch, zypper up) yesterday evening today process “plasmashell” consumes up to 100% CPU, forever. Plasma itself unresponsive, when I’ve “managed” to start an app (like this Firefox session to write this post), apps runs more or less normal.
Found this thread, sounds somewhat similar, except that I’m on Leap and not TW, and that I’ve only an issue with plasmashell, not kglobalaccel.
So I followed the hints and created a new user, logged into Plasma with this plain user. And plasmashell is NOT consuming that much CPU for this other user.
So my question is:
As I’m using my own user for years now, tons of files etc., do we have some sort of cookbook how to “migrate” users when running into issues like these? Or how to narrow down what might be the culprit difference between the two local users, WHY plasmasshell takes so much CPU? I’m somewhat lost in the tons of config/startup files for the user, .bashrc, .profile,… and esp. the several startup files and folders for KDE/Plasma…
First thing I do is to run a process monitor, in tree mode, so that we can see the process dependencies … then scroll the list to check the CPU usage column.
Are we positive the consumer is plasmashell? Maybe it’s some rogue process causing plasmashell usage - if so, we will see it in the tree.
Do you have some process that auto-starts when your regular user logs in?
There might, possibly, be something in the ‘~/.cache/’ directory – you could try logging out from the Plasma session and, cleaning up the Cache from a VT.
If you search in ‘~/.local/share/’ you’ll also find various application Cache directories and files.
In ‘~/.config/’ LibreOffice and the Alphabet/Google Chromium both have Cache directories and, LibreOffice also has one Cache file there.
Apart from that, you could try to access the machine with the rogue user via the network with SSH and then, run either “btop” or “top” from the Command Line to see which process is consuming the CPU cycles.
Have you changed anything with respect to the Linux Kernel Scheduler?
Some problems - and this was one of them - are disappearing by themselves:
I’ve let my Leap 15.6 just running for some hours, on it’s own. Then, after I’ve got the email notification about @myswtest’s answer on my mobile, I did what you recommended and looked into kSysGuard, process tree view, for “plasmashell”.
→ NO ISSUE ANYMORE ← plasmashell consumed ~1h of altogether CPU time, but stays now below 5%, as before. Rebooted again, plasmashell stable, at reasonable low CPU rates.
So seems that whatever process below plasmashell REALLY had to do something, probably after the last (had been many yesterday) updated pkgs. by zypper…
P.S.: @dcurtisfra Looked via “filelight” into ~/.cache… around 9.3GB! kioexec 4GB, thumbnails 2.3GB, winetricks 1GB, 1 GB, …, plasmashell 100MB,…
So probably not the worst idea to clean up in future.
But as it works now again like a charm - never touch running system
I’ve seen this in new kde install because of baloo indexing, IIRC. IDN if baloo is still a thing, I used to disable indexing in system-settings (as it was a pain with HDs and a lot of files) , find works for me.
Yes, Baloo was very problematic many many months ago - many posts appeared out here complaining about its runaway CPU usage.
We’ve also disabled Baloo on all our machines, because it’s useless for us (and would like to avoid any future probs). We know where our files are and yea, find does the job in those rare instances of “where’s it at”?
I’ve had this baloo “indexing forever” issue also, long ago, same machine. Configured that time baloo to include only user’s files into baloo’s indexing. I frequently need to full text search e.g. PDFs. Works fine since then.
BUT as you’ve mentioned baloo I suddenly remembered that I not only applied the patches the day before, but also searched for old digicam photos, on and old external usb hdd… seems that baloo tried to re-index the “thumbnails”… makes sense that this took time but came to an end.
Yes, it’s still a “thing” – but, provided that, it’s used sensibly, it’s OK.
Do not attempt to index the world.
Confine the indexing to only any given user’s directories and files.
If you have a private electricity source and, a powerful CPU and, a system with amazing I/O capabilities then, you can begin to consider file content indexing.
If you don’t have endless energy resources then, confine the indexing to file names.
It makes absolutely no sense to attempt to index system files and directories from a user process.
"powerful CPU" … no :
For my private stuff (no gaming, no development, “Office&Internet”) I have a year 2015 ZBOX nano barebone with an THAT TIME low end “Celeron N2930”. Bloody slow on MSWIN as I’ve read, acceptable on Linux and… SILENT - passive cooled, THE killing argument for me
Put the max. possible RAM (8GB) into it, and a pretty fast 1TB Samsung EVO or so SSD, but a system with amazing I/O capabilities … also no
As written: I REALLY love baloo’s fulltext indexing for my etc. files. And as I ensured that only the /home home dirs are indexed, even on a slow like mine system file content indexing runs pretty fine.
Most of the times
P.S.: Cannot mention often enough that this barebone really was zypper dup-ed from 13.1 via all 42.x to the current 15.6 release… isn’t that amazing??
and yea, find does the job in those rare instances of “where’s it at”?
: