Created attachment 159476 [details] Baloo in System Monitor 1 Every day, Baloo is indexing *something* for hours. System monitor lists open files ./local/shareimime/mime.cache and /urs/share/mime/mime.cache, are they maybe corrupt or something? This hours-long indexing is causing cumulated massive unnecessary power consumption. I don’t know since how long this is a issue but in the summer time, its evident with raising room temperature. The only way is to kill Baloo, day for day. It’s not like there are that much new files, it’s also happening on days with pure surfing. See attached screenshots. Linux: Arch KDE Plasma Version: KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9
Created attachment 159477 [details] Baloo in System Monitor 2
Created attachment 159478 [details] Baloo in System Monitor 3
Are you using the Btrfs filesystem?
(In reply to Nate Graham from comment #3) > Are you using the Btrfs filesystem? And also.... Are you doing content indexing? If so, do you see anything files listed when you run "balooctl monitor" You are killing baloo and seeing the issue reappear on next logon? Or killing and rerunning it? Or have purged with "balooctl purge" and are trying to reindex from scratch? Arch makes use of systemd? Can you see what what "systemctl status --user kde-baloo" gives you? The important info here is the memory usage. Has it just started? (maybe with Frameworks 5.106.0?)
Nearly all my filesystems are btrfs, with Zstd compression. Yes, content indexing is on. balooctl monitor just shows "File indexing running, Checking for changed index entries" (translated). Yes, it’s happening over and over again after relogons. I’m not rerunning it manually. I haven't used the purge command yet. systemctl status --user kde-baloo ● kde-baloo.service - Baloo File Indexer Daemon Loaded: loaded (/usr/lib/systemd/user/kde-baloo.service; disabled; preset: enabled) Active: active (running) since Tue 2023-06-06 18:40:24 CEST; 22min ago Process: 1382 ExecCondition=/usr/bin/kde-systemd-start-condition --condition baloofilerc:Basic Settings:Indexing-Enabl> Main PID: 1383 (baloo_file) Tasks: 4 (limit: 38385) Memory: 512.0M (high: 512.0M available: 0B) CPU: 9min 34.248s CGroup: /user.slice/user-1000.slice/user@1000.service/background.slice/kde-baloo.service When did this start… I cannot say for certain. I have witnessed it for a longer time but mainly ignored it. Maybe even years? I’m just fed up with this situation as of today. Is there a command to show which file Baloo tries to index?
Ok, if you're on Btrfs, it's Bug 402154. *** This bug has been marked as a duplicate of bug 402154 ***
(In reply to Maximilian Böhm from comment #5) > Memory: 512.0M (high: 512.0M available: 0B) My suspicion is that the systemd service definition has capped the memory that baloo can use. This looks very much like Bug 470382. There's a description of what you can check here: https://bugs.kde.org/show_bug.cgi?id=470382#c1 You can try: systemctl --user edit kde-baloo and change the MemoryHigh=512M to MemoryHigh=50% I'm not 100% certain here because... > When did this start… I cannot say for certain. I have witnessed it for a > longer time but mainly ignored it. Maybe even years? I’m just fed up with > this situation as of today. ... you've had problems for a while, the 512 MByte limit is quite recent. > Is there a command to show which file Baloo tries to index? Yes, "balooctl monitor". However this shows you the files as baloo does its second phase "content indexing". I suspect that the indexing *something* is the first phase, when baloo is scanning the system looking to see what's new or changed.
Thanks! MemoryHigh=50% has worked somewhat: Now, balooctl monitor shows me a list of the files it is indexing. But it does seem to index the full partitions again and again. Looks like I am affected from both problems, the memory limit and the btrfs issue. Unbelievable that this bug on btrfs systems was first reported in 2018! O.o Don’t KDE devs use modern file systems? Dear god, what a massive unnecessary power consumption over all those users over all those years.
(In reply to Maximilian Böhm from comment #8) > ... MemoryHigh=50% has worked somewhat: Now, balooctl monitor shows me a list of > the files it is indexing ... That's good. One step along the way... > ... But it does seem to index the full partitions > again and again. Looks like I am affected from both problems, the memory > limit and the btrfs issue ... There is a draft Merge Request here: https://invent.kde.org/frameworks/baloo/-/merge_requests/131 That proposes a "lightweight" fix, it's nice in that it would not force a purge and reindex (the internal ID's that baloo uses are still 32 bit) but it isn't a comprehensive solution. > ... Don’t KDE devs use modern file systems? ... I'm not sure I'm the right person to answer that one :-) I imagine though, if you are developing, you want a completely stable, reliable base system. No extra unknowns. You would then test in different environments. What interesting is that earlier the BTRFS issue initially caught mostly OpenSUSE users, that system set up a lot of subvolumes and ran into trouble. Fedora, also with BTRFS, only rarely showed problems historically but that's changed with recent releases.
(In reply to Maximilian Böhm from comment #8) > ... MemoryHigh=50% has worked somewhat ... There's discussion here: https://invent.kde.org/frameworks/baloo/-/merge_requests/124 about the recent change to cap the baloo memory usage