https://bugs.kde.org/show_bug.cgi?id=500665
--- Comment #58 from Oded Arbel <[email protected]> --- (In reply to tagwerk19 from comment #57) > (In reply to Oded Arbel from comment #56) > > I think I have the same issue - baloo_file takes ~300M of RAM and ~50% of a > > CPU, and htop shows it in D status all the time, while balooctrl6 monitor > > says > > "Idle (Powersave)" and shows no traffic. > It's possible it's clearing the records for files that have been deleted. > You wouldn't see that in the monitor, you might see baloo_file (not > baloo_file_extractor) busy with htop or iotop As I mentioned - that is what I'm seeing in htop: baloo_file eating RAM and doing IO blocking while pegging the CPU in a high power state. > Think that that's the memory that Baloo uses as "cache", quite possibly used > by clean pages that get dropped when something else needs the space. htop lists the ~400M RAM as RES, which - AFAIK - means less RAM for other things. If you mean "dropped" as in goes to swap, then that's no good - I'm running without swap because of a small disk (or I set up a few GB swap file when I really really need the extra VM because I'm running a large workload). Swap VM is not free. > The > memory is shared between the always-running baloo_file and the > when-there-are-things-to-index baloo_file_extractor. > > The 1% of the time. 512MB is constricting. Not enough - this is how my system currently look: ---8<--- ● kde-baloo.service - Baloo File Indexer Daemon Loaded: loaded (/usr/lib/systemd/user/kde-baloo.service; enabled; preset: enabled) Active: active (running) since Wed 2025-04-16 18:19:23 IDT; 1 day 6h ago Process: 5471 ExecCondition=/usr/bin/kde-systemd-start-condition --condition baloofilerc:Basic Settings:Indexing-Enabled:true (code=exited, status=0/SUCCESS) Main PID: 5487 (baloo_file) Tasks: 7 (limit: 37870) Memory: 638.2M (high: 512.0M available: 0B peak: 656.2M) CPU: 8min 47.429s CGroup: /user.slice/user-1000.slice/[email protected]/background.slice/kde-baloo.service ├─5487 /usr/lib/x86_64-linux-gnu/libexec/kf6/baloo_file └─6621 /usr/lib/x86_64-linux-gnu/libexec/kf6/baloo_file_extractor Apr 16 22:30:26 vesho baloo_file_extractor[6621]: kf.baloo: Not busy, fast indexing ... many of those log lines ---8<--- Its 638MB out of 512MB (!!). It's mostly baloo_file_extractor, with baloo_file taking only about 100MB. monitor still says "Idle" and status says: Baloo File Indexer is running Indexer state: Idle Total files indexed: 5,827,389 Files waiting for content indexing: 4,051 Files failed to index: 68 Current size of index is 7.85 GiB > I think a 25% maximum is reasonable, a 40% maximum (and zero swap) is also > possible. 40% of system RAM for the background file indexer? That seems atrocious to me. When I run a development workflow I need all the RAM that I can get, to the point that I clear trashes and caches and set up a swap file. Spending 25% of my RAM on a background file indexer - Idling -`seems insane to me. But my main problem - which I think is the OPs as well - is that baloo_file (not extractor) sometime pegs the CPU. Keeping the CPU in a high power state is not free: it costs battery life and available time off AC, not to mention heating and fans. I like the features I get from baloo, but if I need to manually handle the state of the background indexer (turning it off when I leave my desk, or need to start a large workload), then there is a problem. -- You are receiving this mail because: You are watching all bug changes.
