SUMMARY The `baloo_file` process starts on ym computer every time I login. It does not go away and will pin my SSD to 100% usage forever and eat up 300mb of memory. STEPS TO REPRODUCE 1. Log in. OBSERVED RESULT Baloo will start and never stop indexing regardless of what happens EXPECTED RESULT Baloo does not start, and if it does it will stop within a reasonable time SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.12.8-zen1 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 ADDITIONAL INFORMATION
(In reply to Pyx from comment #0) > ... pin my SSD to 100% usage forever and eat up 300mb of memory. Three possibilities here... One that you've added/changed a large number of files. That should not be an issue since the BTRFS bug was fixed (quite some time ago, https://invent.kde.org/frameworks/baloo/-/merge_requests/131). However, if you are using BTRFS, have not reindexed since then and your index is larger than your RAM (as a rough indicator), then kill Baloo, purge and reindex. Second, if you are I/O bound and Baloo is using *only* 300 MB is a bit strange. When run under systemd, the unit file for Baloo rather strictly limits RAM use to 512MB (you can check with "systemctl status --user kde-baloo"). That can be low and Baloo ends up repeatedly re-reading info from the index rather than having it "there", cached in memory. That I/O might be reads... but... Third, if you've recently deleted a large number of files. Baloo doesn't batch up deletes in the same way as it batches up indexing requests (it normally indexed 40 files in a go and commits the results to the index). When you delete files, they are removed from the index one by one which can be a lot of work. Again, it might be worth looking at the size of the index (the file is under ~/.local/share/baloo)
(In reply to tagwerk19 from comment #1) > ... Three possibilities here ... Did any of the three fit with your situation? It would be interesting to know if you purged and restarted the indexing you got any further. Following on from the second possibility (that Baloo is too strictly limited by the systemd Ram limits in the unit file), you can quite safely increase this, have a look at: https://bugs.kde.org/show_bug.cgi?id=470382#c2 You can try 25% first (rather than 512M) and see if it makes a difference.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
(In reply to tagwerk19 from comment #2) > (In reply to tagwerk19 from comment #1) > > ... Three possibilities here ... > Did any of the three fit with your situation? > > It would be interesting to know if you purged and restarted the indexing you > got any further. Following on from the second possibility (that Baloo is too > strictly limited by the systemd Ram limits in the unit file), you can quite > safely increase this, have a look at: > https://bugs.kde.org/show_bug.cgi?id=470382#c2 > You can try 25% first (rather than 512M) and see if it makes a difference. Sorry, lost the email to this for a bit. I haven't seen it happen for a bit so I'm assuming it was a weird bug which got fixed by now.
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.