Bug 488645

Not many leads here are there...

My guess is that Baloo is working within its memory "cap" (it has a 512MB limit defined in its systemd unit file) but the index has grown far too much. It will struggle when reading - it will read scattered pages from the index, have to repeatedly drop "clean" pages to read another ones, repeat and repeat. Means loads of I/O.

When indexing you have this behaviour and a possibly a gradually increasing number of dirty pages that cannot be dropped. That may push Baloo to start swapping. That is *bad*.

This has to be a guess from your description. A 6GB index seems large. You could see what
     systemctl --user status kde-baloo
says and you could watch what's happening with I/O with iotop. Maybe try increasing the 512MB limit (MemoryHigh) to something like 25% (it's a bit of a 'pick a number'), which should allow Baloo to make better use the RAM. As a separate step, perhaps afterwards, you could set the MemorySwapMax to zero (means that if you reach the limit, Baloo will be killed OOM rather than running your system into the mud). You can edit these settings with:
     systemctl --user edit kde-baloo

I am linking https://bugs.kde.org/show_bug.cgi?id=446071

For both my laptops, "baloo_file_extractor" went crazy after copying over 200gb of files from my Windows session. The files are all kinds of .img (gps maps), zip files, Ms Office files etc.

Laptop 1 had 32gb in memory and 2tb SSD, and Laptop 2 16gb in memory and 512gb SSD. Both systems rendered inferior to Windows 11 (massive loss in battery time) due to "baloo_file_extractor" which I had to turn off after 10 hours of constant processing.

(In reply to Fieldservice4 from comment #2)
> ... For both my laptops, "baloo_file_extractor" went crazy after copying over
> 200gb of files from my Windows session ...
See: https://bugs.kde.org/show_bug.cgi?id=446071#c20

But also it would be interesting to see if Baloo was picking up files it should not index. I remember there have been bugs about it stumbling on Wine folders.

I think first make sure it is not running the content indexer when on battery then watch what it is indexing with "balooctl monitor" (maybe "balooctl6 monitor") when you are on mains power.


. The files are all kinds of .img (gps
> maps), zip files, Ms Office files etc.
> 
> Laptop 1 had 32gb in memory and 2tb SSD, and Laptop 2 16gb in memory and
> 512gb SSD. Both systems rendered inferior to Windows 11 (massive loss in
> battery time) due to "baloo_file_extractor" which I had to turn off after 10
> hours of constant processing.

Has there been any progress on this issue? I had a similar issue, where the baloo_file process was taking around 96% of my cpu even though the file search screen in the settings said that the indexer was paused. I could get around this by simply killing the process, and now that it says the index is 100% complete, I haven't encountered the issue again, but at the time this problem did cause my laptop to noticeably heat up. Let me know if there is any solution for this!

System Details

Operating System: Fedora Linux 40
KDE Plasma Version: 6.2.3
KDE Frameworks Version: 6.8.0
Qt Version: 6.7.2
Kernel Version: 6.8.5-301.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7840U w/ Radeon 780M Graphics
Graphics Processor: AMD Radeon 780M
Manufacturer: Framework
Product Name: Laptop 13 (AMD Ryzen 7040Series)
System Version: A7

This still happens. I still can't see any file being indexed in /proc/fd or `lsof -p NNNN`.

I ran strace and baloo_file_extractor is every 15 seconds or so doing lseek(), writev(), and pwrite64()s to  FD 16, which is its $HOME/.local/share/baloo/index file. My baloo index file is 5.5GB.