[kde-linux] baloo_file_extractor - huge disk usage?

[Duncan]

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.

>    While writing this message the disk light has gone back to no
> activity, the machine is responsive and the baloo_file_extractor app is
> no longer using io.
> 
>    So, the basic question is how do I turn this off or at least get it
> under control as it's causing huge problems when it occurs?
> 
>    If this isn't the right list please advise where is better. Maybe
> it's a distro issue.

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!

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.

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.

---
[1] MS at the turn of the century: I haven't allowed MS on my systems 
since the introduction of eXPrivacy shortly after the turn of the 
century, as it crossed a line I simply wasn't going to cross.  Funny that 
many of the people who objected to eXPrivacy back then, like frogs in a 
heated pot, are now swearing by eXPrivacy, as MS Windows 10 goes even /
further/ down that path.  I guess MS is counting on them to protest a bit 
as they did last time, but ultimately, continuing to sit in the pot until 
they're well boiled.  <shrug>  Well, I for one, didn't!  For that reason 
I've little knowledge beyond what I read of what MS does today, nearly a 
decade and a half later.

[2] Semantic-desktop related flags/packages: Back then, rasqual, 
virtuoso, nepomuk, akonadi, etc, some of which will no longer be valid 
with baloo, but I'm not sure if the deps have actually gone away or have 
only been replaced with other deps.  I did have to keep strigi as some kde 
packages (kdelibs and kde's systemsettings are the two I have installed 
that still dep on it) apparently link to its headers without a disable 
option, but with all its backends turned off, it couldn't actually do 
anything, so other than having to still have it installed to link to, 
it's pretty impotent.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman