[kde-linux] baloo_file_extractor - huge disk usage?

Mark Knecht markknecht at gmail.com
Fri Aug 14 00:24:21 UTC 2015

Hi Duncan

On Thu, Aug 13, 2015 at 5:02 PM, Duncan <1i5t5.duncan at cox.net> wrote:
> Mark Knecht posted on Thu, 13 Aug 2015 14:36:35 -0700 as excerpted:
>>    I'm not sure if this is a Gentoo issue or a KDE issue so I'll start
>> on the KDE list. Thanks in advance.
> Arguably, it's a kde as upstream issue, but gentoo offers the possibility
> of mitigating it, arguably more than most binary distros. =:^)


>>    I have a problem that's developed recently. The basic symptom is
>> the machine slows down horribly at some point in the afternoon with the
>> disk activity light is full on - no blinking at all. This results in all
>> applications - Virtualbox, Chrome, etc. - essentially ceasing to operate
>> correctly and KDE to sometimes locking up for 5-10 minutes.
>> Due to recent messages from Gentoo devs requiring baloo I've started
>> looking there.
>>    When I'm in this state where disk activity appears to be 100% I see
>> large wait percentages in top. (3 CPUs in this state right now.) Running
>> iotop it appears that something called baloo_file_extractor is spending
>> 99.9% of its time waiting.
> Yeah... that behavior is why I decided the (small to me) benefits of
> semantic-desktop in general weren't worth the down side.  Tho the
> tradeoff is arguably different for each person/use-case, the basic
> problem remains the exact same one it was back before the turn of the
> century[1], when the first thing most computer-knowledgeable folks did to
> an MS Office installation was disable its indexer functionality.

OK, so the KDE documentation suggests that it can be turned
off using System settings -> Desktop search and at the bottom there's
an entry for 'Enable Desktop Search' so I've unchecked that and will
see how it goes tomorrow.

> While it might be possible to throttle baloo to some extent (I'm not
> actually sure because like the nepomuk before it, it's banished from my
> system), and at least back in the nepomuk era when I rid myself of it, it
> was in theory possible to turn off at runtime, at least in my experience,
> actually building kde with USE=-semantic-desktop (obviously not an option
> on distros where the binaries come pre-built, thus my remark above about
> gentoo making a workaround easier) and without related flags and packages
> [2], then depcleaning them from the system, made kde *SURPRISINGLY*
> faster.  "Surprisingly", because I /thought/ the runtime turnoff actually
> did so, and the build-time disable and depclean was primarily to clean up
> the dependencies.  But /something/ was obviously still sucking
> performance as I'm not kidding, after getting it off the system entirely,
> it was as if I suddenly had a couple extra cores or had upgraded at least
> a half a GHz in cpu speed, which REALLY surprised me.  It felt like I
> guess the MS users must feel after they get the malware cleaned off!

In that regard there are two packages that use the flag, dolphin & gwenview.
Depending on how things go tomorrow just having disabled it I'll give rebuilding
those two a try.

> While I can't guarantee similar effects to everyone, ridding your system
> of semantic-desktop and the baloo indexer and akonadi, should at minimum
> guarantee that it won't run and effectively lock you out of normal
> operations on your system for minutes at a time.

One would hope!

> And actually, the gentoo/kde devs have recently cleaned up the old
> akonadi deps in the old pre-akonadi-kmail kdepim-4.4.x series as well, so
> you shouldn't even require akonadi and via it, semantic-desktop, for the
> non-akonadi kmail/kdepim stuff, either.  The other alternative being to
> switch to non-kdepim solutions for mail and related (IM, feed-reader,
> etc).  I've been rather happy with claws-mail since I switched to it
> here, altho the migration from kmail isn't as simple and easy as I would
> have liked.
> If you have detail questions and would prefer to take it to the gentoo-
> desktop list (or gentoo-amd64, but the desktop list is more topical),
> that's fine, or continue here if you like, since it /is/ kde-linux
> related, and I'm on both this the kde-general and kde-linux lists and
> those gentoo lists.

I'll try these ideas out over the next few days and see what happens. I
generally just use locate to find things so none of this overhead is necessary
for my normal day to day life.



More information about the kde-linux mailing list