After upgrading from x11/kde4 to x11/kde5, I found there is a process called 'baloo_file' which seems to use a lot of system resources. If I forget to kill it within minutes after starting a GNOME session, the entire system will freeze. Yes, installing KDE can affect GNOME, as /usr/local/etc/xdg/autostart/baloo_file.desktop has X-GNOME-Autostart-enabled=true. I can change it to false to avoid the problem in GNOME, but it sounds like a workaround.
When baloo_file freezes the system, I can still move the mouse but no desktop applications are responding. SSH server becomes almost non-responsive and it takes several minutes just to get a login shell. Typing any simple commands such as 'killall' takes minutes to complete, and even logging in from a local VT is hard. When you type your user name, it takes several minutes to show the password prompt. If you press Ctrl-T at that time, you will see the following message.
load: 0.47 cmd: login 1141 [vlruwk] 204838.88r 0.00u 0.00s 0% 240
Most of the time it is stuck at [vlruwk] or [ufs] while the system load is low. I am not sure whether it is related to the number of files under my home directory. My home directory has about 2500000 files because I store hundreds of git repositories, mostly GNOME source code, and builds of GNOME and FreeBSD in it.
You can disable baloo via "balooctl disable". Or you can configure it to not index certain directories.
It would be interesting to know how many files baloo_files has open, and how many are free / available by the system.
I suspect this might be related to the fact that SDDM doesn't apply resource limits. There's a patch for this: https://reviews.freebsd.org/D17297
Could this be related to bug #234830?
(In reply to Martin Birgmeier from comment #3)
I don't think so. The file in this one just seems to hang libtiff.
I've just realized that even with SDDM patched to apply resource limits, there is no default limit for "openfiles".
Would it be possible to modify libinotify to limit itself to eg half of kern.maxvnodes?
(In reply to Edward Tomasz Napierala from comment #5)
Probably yes -- over to the maintainer of libinotify.
From bug 257227 comment 1 (emphasis more on baloo_file_extractor than on baloo_file):
> … I should, ideally, positively identify the cause of
> hogging in my case, but this will be a bug for another day.
(In reply to Tobias C. Berner from comment #1)
> … It would be interesting to know how many files baloo_files
> has open, and how many are free / available by the system.
Reading the above _loosely_ alongside bug 234830 (closed, fixed) …
If it's true that some types of file are more likely to trigger high CPU usage, when handled by baloo_file or baloo_file_extractor, will it help to identify those types?
> Baloo relies on KFileMetaData to extract content from the files.
> KFileMetadata ships with a number of plugins which can be enabled
> or disabled. We recommend shipping all KFileMetaData plugins. Specially
> ffmpeg by default. Without the indexers, Baloo cannot function to its
> full potential.
% pkg info --list devel/kf5-kfilemetadata | grep plugins
% uname -KrU
14.0-CURRENT 1400025 1400025
% pkg info -x metadata