https://bugs.kde.org/show_bug.cgi?id=500665
Vyacheslav Kovalevsky <slava0...@vk.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |slava0...@vk.com
--- Comment #65 from Vyacheslav Kovalevsky <slava0...@vk.com> ---
(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
>
> > 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.
It has been really awful for me too, system being sluggish unresponsive for
seconds (and minutes sometimes!). Ballo file extractor was not really showing
up in KDE System Monitor (it said it was using very few resources, like 1%, no
spikes, nothing), but when I run ioctl I saw it actually used a lot of disk IO.
I have a lot of files on my Ext4 drive (compiling kernels, creating many QEMU
images etc.), and it was very awful when computer straight stopped responding,
I almost considered reinstalling OS (I am using Arch Linux).
--
You are receiving this mail because:
You are watching all bug changes.
