https://bugs.kde.org/show_bug.cgi?id=460460
--- Comment #2 from Adam Fontenot <adam.m.fontenot+...@gmail.com> --- (In reply to tagwerk19 from comment #1) > (In reply to Adam Fontenot from comment #0) > > 2... probably resulting in the deletion of some > > temporary files. (See the linked bug above describing heavy disk write > > caused by file deletion.) > > 3. Try to check on Baloo's status... > Maybe Bug 437754. So in this bug, the act of checking on Baloo's status is what triggers both memory use and i/o thrashing followed by bloating the database? That's ... insidious. Lines up pretty well with my experience, given that I was sitting at around 0.5 GB used for months before I had this problem. > I'm guessing you had been doing content indexing previously and had disabled > it - otherwise 0.5 Gbyte seems a little large. I'd need to check to see > whether baloo "cleans up" content records in this situation or just leaves > them "orphaned". No, I've had content indexing disabled for a while (due to the innumerable bugs I've encountered with it) and previously deleted the database. So that 0.5 GB was whatever it was previously using. Unfortunately no way to check that now, as I was forced to kill the process and delete the database because of this issue. For reference, my home folder has about 500k items, of which about 180k are supposedly excluded (being in cache or source code directories I have marked as "not indexed" in the settings). > Second thought is that if baloo_file sees a large number of unindexed files, > it first collects the metadata for all of them, then writes the all results > to disc. This can give a sharp peak in memory usage and, in extreme cases, > bog down the system. > > Note in this case, the work that baloo_index is doing is invisible to > "balooctl status". This is part of what I'm advocating here; there should be no work done by Baloo that is invisible to `balooctl` or is unkillable by the user. (There may be work that we strongly prefer the user not interrupt, but ultimately if we don't provide a way for them to do it nicely they're just going to `kill -9` the Baloo processes.) > Off-chance thought... > > Can you see out what temporary files Audacity creates? Might baloo want to > index them? (Are they hidden or not? what does kmimetypefinder say about > them?). It is an off-chance as if you are not content indexing, this > shouldn't affect you. Checked on this, the files are actually created in /var/tmp, so not relevant here. Most likely what happened is that just before opening Audacity I decided to clear up some free space in order to be able to export files. These were mostly a bunch of large source code directories that I had extracted in my downloads folder (which is indexed) while I was debugging something. It's entirely possible that Baloo was still hung on those by the time I closed Audacity. > What filesystem are you using? If you are using BTRFS, there'll be a > follow-on set of questions.... I am indeed using BTRFS. -- You are receiving this mail because: You are watching all bug changes.
