Our local school is 100 % Rocky Linux 8, not only the servers, but also two dozen desktop clients. The /home directories are all on the servers and exported via NFS, and authentication is also centralized on the server. We’re using KDE from EPEL as desktop environment on all machines (for the record in case someone from Red Hat reads this: we gave GNOME a spin, and everybody hated it). So far, this setup works nicely.
One problem though. Some folks need to use desktop search. So I activated file indexing in the KDE configuration. Under the hood, KDE uses the Baloo file indexer as far as I understand. I’m using it myself, and it works nicely, since it also indexes file contents, so you can perform searches inside documents also.
The school’s director has much more data than other users, and here’s the problem. When he activates file searching, his desktop environment becomes extremely sluggish so as to be nearly unusable. So I figure this has to do with /home being on the server and the file indexer not having the necessary I/O performance disk-wise and/or network-wise.
I know (at least theoretically) there’s the possibility to renice processes, and I wonder if there’s something like that I could do here, though I wouldn’t exactly know where to start.
I fully understand your take on the current Gnome desktop, but then I’m an xfce guy, so to each his own
I think the problem here may not be only the director’s large number of files compared to others; actually, baloo likely is fully reindexing all of the director’s /home on a regular basis (!).
I recall there being reports of near-constant baloo indexing activity on nfs and other remote shares a few years ago… interestingly enough, this appears also to be an issue with BTRFS systems now, as well, as detailed on bug 471289 at bugs.kde.org .
A quick summary of the problem is that some devices and filesystems present themselves to the kernel with a different device number between system reboots and/or potentially even network share remounts; since the existing baloo code “stamps” its index based on that device id (in addition to inodes), this causes baloo to re-index the entire tree of files again if and when that device id changes. A performance hit might not be nearly as noticeable on relatively-small /home directories, even if they are subject to the same problem.
It appears the baloo developers are working on a fix for this issue for some filesystems and device types, but there are several complicating factors on how (or if) a resolution can be found for nfs shares.
If nothing else, I’d recommend checking the indexing status (index size, number of files, etc.) for the director, and verify the index isn’t becoming ridiculously large.
Check out the usage for commands such as “balooctl monitor” and “balooctl status” on the KDE.org Baloo Debugging page .
Hope this helps. Also–I absolutely love hearing about schools using linux in pretty much any aspect–good show!
