https://bugs.kde.org/show_bug.cgi?id=500665
--- Comment #57 from tagwer...@innerjoin.org --- (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 > The kde-baloo.service on my system (Neon) has a limit of 512MB, which seems > quite high to me - that's a significant chunk of memory for a background > service that is supposed to be idle most of the time. 99% of the time 512MB is a good limit. 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. This 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. If you are indexing a lot and are building a big transaction, you've got dirty pages that cannot just be dropped. Maybe they get swapped (and you *really* don't want that). If you are in that 1% territory, you see Baloo slowing as systemd(?) delays giving it extra memory - Baloo spends its time reading, dropping, rereading, dropping and re-rereading clean pages that it needs. I've not kept an list of bugs that could very well be the result of the constraint but there have been a slow and steady stream. In general you suggest increasing the cap and the issue goes quiet, reasonable to assume that people are happy. I think a 25% maximum is reasonable, a 40% maximum (and zero swap) is also possible. From my experience neither of these impact system performance even with pathological test cases. -- You are receiving this mail because: You are watching all bug changes.
