High CPU load after login for several minutes

Hi,
I installed Leap 42.2 a little over a week ago and used it every evening since then. It happened for the second time today that the CPU load after login is very high, so high that the system sometimes needs several seconds to react on a mouse klick.

The strange thing is that I cannot figure out what causes the high CPU load. “ps -aux” doesn’t show anything that needed more than a few seconds. kSysGuard shows the high CPU load, but no process that needs more than 5%. It showed “ls” and “find” for a short time, so maybe something is searching my file system (I have two SSDs, so file access isn’t audible).

I have a dual-core CPU and at least one core is at 100% 90% of the time.

The first time I had this problem it went away after some minutes. This time, after about 15 minutes, I disabled ‘File search’ in “System Settings/Search” and “Search Folder Updater” in “System Settings/Background Services”. The CPU load went down, but this might have been a coincidence.

I had a similar problem a long time ago (with 13.0 or 13.1) and back then the culprit was a demon that build a search index. I fixed it by disabling this demon.

Any idea what may cause the high CPU load and why I can’t detect it with “ps -aux”?

Thanks, Stephan

Still, it may be file searchers and indexers. They may take a lot of disk access resources, in addition to CPU resources.

If you don’t need those services, try to uninstall in Yast as much as possible packages that contain akonadi and baloo in their names, estimated about 20.

Disabling those “helpers” is not an easy thing. Their controls and components are spread around, and they have a tendency to recover themselves. After installing a version of openSUSE or Leap, I do the uninstalls, and prohibit the future installations in Yast by selecting “Taboo – Never Install”. In addition, I disable file search operations in configuration menus. Some package dependencies will be broken and some information will not be readily available in GUI, of course, but I don’t miss it.

Also read the manual of
ps
to see other options. I often use
ps -ef

I use this to give me a list of top 10 CPU users:

ps -eo pcpu,pid,user,args | sort -k 1 -r | head -10

Another thing to keep in mind would be to opt for a less resource heavy GUI like xfce or lxde instead of Gnome or KDE especially if you are running on older hardware.

Installed Leap 42.2 two days ago. And succeeded in configuring kdeconnect.
Today, I’ve noticed fan noises without a reason. I started ksysguard, and noticed that kdeconnectd was using 25% CPU. Maybe this is also the culprit in your case?
Anyway, for the time being I killed the deamon and everything is fine, but I will try to dig further…

There are good reasons for suspecting this may be file indexing (ie, the symptoms) and you should understand why ‘ps -ef’ (and variations thereon) are pretty much useless when it comes to nailing down this kind of problem.

Essentially there are likely to be two things doing file indexing; locate/updatedb/find and the DE Akonadi things. Now for me Akonadi does nothing useful and should be disabled in the ‘KDE System Settings’ as soon as possible. On the other hand for me locate is something that I genuinely do use, so I leave that in place. I don’t find the ‘down time’ to be as bad as with Akonadi but your mileage may vary.

Now to ‘ps’. The problem is that you do not have an application doing much file I/O, you have the kernel doing a lot of file I/O for an application, so all you are likely to find out from the ‘ps’ approach is that the kernel is busy. KDE System Guard is likely to be better as it shows file I/Os per application (if correctly configured) but still it is a bit indecisive as use of CPU time isn’t totally proportional to number of I/Os.

Thanks for all the feedback.
I hope a dual-core CPU running at 3.2GHz and 8 GB RAM doesn’t qualify as old hardware.

It happened again today. The system was unresponsive after login and ksysguard showed both cores at 80% or more. After 10 minutes, if was down to 1 core at 100%. That went on for another 10 minutes or so.

I disabled all search plugins in the system settings dialog a few minutes ago. When I reopened the system settings window, they were all selected again. I did it a second time and noticed that it takes about a minute before they are all enabled again. ???

I noticed that a ‘directory watcher’ service is running. It’s a ‘on-demand’ service. According to the help, I cannot disable it.

Looks like I really have to uninstall some packages.

Thanks, Stephan

PS: I installed Leap 42.2 with Gnome desktop on a second computer. No such problems. File search works immediately as expected. Unfortunately, I like the KDE GUI much better than the Gnome GUI.

Oh boy… no more dolphin. I intentionally uninstalled akonadi and baloo and that uninstalled dolphin. When I re-install dolphin, I get baloo again. But I need Dolphin.

As you can see with the following command:


LT_B:~ # zypper --no-refresh info --requires dolphin |grep [Bb]aloo
    libKF5Baloo.so.5()(64bit)
    libKF5BalooWidgets.so.5()(64bit)
    baloo5-kioslaves
LT_B:~ #

Dolphin REQUIRES a few Baloo components. Those in turn are provided by even more packages…


LT_B:~ # zypper --no-refresh se --provides baloo5-kioslaves libKF5Baloo libKF5BalooWidgets
Loading repository data...
Reading installed packages...

S | Name                     | Summary                                       | Type   
--+--------------------------+-----------------------------------------------+--------
  | baloo5-kioslaves         | KIO slave components for Baloo Framework      | package
  | baloo5-widgets           | Framework for searching and managing metadata | package
  | libKF5Baloo5             | Core library for Baloo Framework              | package
  | libKF5Baloo5-32bit       | Core library for Baloo Framework              | package
  | libKF5BalooEngine5       | Baloo Engine library                          | package
  | libKF5BalooEngine5-32bit | Baloo Engine library                          | package
i | openSUSE-release         | openSUSE                                      | package
LT_B:~ #

…so in the end Baloo gets reinstalled. To avoid that, as ZStefan suggested in post #2, uninstall Baloo and, BEFORE reinstalling Dolphin, select “Taboo – Never Install” for each package with baloo in its name.
Then re-install dolphin and accept “break dependencies for Dolphin” or similar when Yast2-Software complains about the missing dependencies.

Yes, but these components are not really related to file indexing, just to be able to use the index if it exists.
And baloo-widgets is actually unrelated to baloo, it provides the file metadata display for dolphin. Again, it will take this information from baloo’s index if available, but it doesn’t need the indexer to run at all.

…so in the end Baloo gets reinstalled. To avoid that, as ZStefan suggested in post #2, uninstall Baloo and, BEFORE reinstalling Dolphin, select “Taboo – Never Install” for each package with baloo in its name.
Then re-install dolphin and accept “break dependencies for Dolphin” or similar when Yast2-Software complains about the missing dependencies.

Sorry, but that’s really bad advice, and likely will make dolphin not start at all (though I haven’t checked).

The file indexer is in the package baloo5-file, you should only uninstall that, and there will be no more indexing.
Or disable file indexing in the settings.

Akonadi is something completely different anyway, and will only be started if you run some application that uses/needs it, like kmail.

But the original problem in this thread seems to be unrelated to baloo (and akonadi) anyway:

That’s probably from updatedb (which runs as daily cron job) as has been mentioned too already.

Another thing that can cause heavy IO (and slow down the system while it’s running) is btrfs’s balance/cleanup script, that is run weekly (by a cron job as well).

OK, point taken. I admit to not having any knowledge of Baloo internals; I was only trying to explain what apparently works for ZStefan according to post #2.

Hi,

it turns out Dolphin was the least of my problems. When I wanted to shut down my computer, I selected the shutdown icon from the start menu (as usual) and… nothing happened. I then logged in as root and used

shutdown -h now

That worked, but I can’t start it now. After the the window with the three dots in the middle, the screen goes black and an underscore is visible in the upper left corner. Nothing happens then. I started run level 3, logged in as root, started yast and tried to re-install akonadi. I got some error messages and ended up installing only a subset of the akonadi packages. Anyway, it still doesn’t start KDE. Not surprising, as I uninstalled several other packages I thought I don’t need yesterday. I don’t remember what they were.
Any ideas on how to repair my system?

Thanks, Stephan

PS: I’m writing this from Leap 42.1, which I have still installed on another partition

Well, you could try to run “zypper ve” and allow it to fix the system.

Or try “zypper dup --no-allow-vendor-change”, that should reinstall all missing packages automatically I think.

Other than that, I would recommend to login to IceWM (or just run “startx” or maybe ‘WINDOWMANAGER=“icewm” startx’ as root if you cannot even get a login screen) and then run startkde in a xterm window. That should give you some errors about missing libraries which you should install then.
If you need help, post the error messages.

Btw, reinstalling akonadi won’t help as akonadi is not required by the desktop.

Thanks. I"m not familiar with zypper and happend to realize that startx as root starts a ICEWM before I read your post. I then used yast to install the KDE environment (only some of the packages were already installed). Using yast with mouse was much easier than without (even though I already used yast when that was normal).
I hope I have at least a week before the original problem occurs again…

Stephan