https://bugs.kde.org/show_bug.cgi?id=404057
--- Comment #51 from Kai Krakow <k...@kaishome.de> --- (In reply to tagwerk19 from comment #50) > (In reply to Kai Krakow from comment #49) .... > > Thank you for the insights. That's a lot more to think about... You're welcome. > What we had previously, of BTRFS presenting "another different" device > number on reboot and Baloo's initial scan for changes not committing at > intervals, that was a catastrophic combination. I initiated the idea to fold the uuid into the dev/inode feels somehow, I just hadn't time exploring the source code. Luckily, someone finally implemented that idea. \o/ > I think, in *general*, > nowadays Baloo does not demand so much memory. Maybe though I should check > when a lot of files have been deleted and Baloo has to catch up. How Baloo > might behave when it is squeezed for memory (rather than being the culprit), > that's something new to think about... Yeah exactly. I think one remaining issue is when system performance suffers not because baloo uses too much memory but because it becomes squeezed into too little memory. Thanks for testing it. I'm currently running fine with `MemoryLow=512M` and no high limit, seems to work great so far even with games running and while streaming, using btrfs on bcache with hdds. With that configuration, more baloo memory has been pushed into swap - but it was never reclaimed so its probably inactive memory anyways and should be in swap. I'd recommend to look into the "below" tool (an alternative implementation to "atop"), it tracks memory usage via cgroups and thus can tell you also the accounted cache memory of a process group where "htop" or "top" only show resident process memory without caches accounted. -- You are receiving this mail because: You are watching all bug changes.
