Comment 96 for bug 578215

I can confirm the problems with KDE PIM/Akonadi. But my own experience is a little different. 2 different machines, one running Ubuntu, the other one Fedora.

1. I began with almost empty databases, because of the known problems with migration between KDE PIM 4.4.x and KDE PIM/Akonadi. With Fedora, I couldn't trigger the bug, but with Ubuntu I triggered the Virtuoso bug more than once. I narrowed it to the Akonadi-Nepomuk Email Feeder.

2. To workaround the issues I was experiencing with Kubuntu, I tried to remove and recreate the resources with Akonadi Console, and after a try, mail began to flow and Virtuoso core-wasting somewhat stopped. The behavior of Virtuoso this time was different: it was using ~70% of one core, while akonadi_nepomuk_email_feeder was shown as running. Certainly, akonadi_nepomuk_email_feeder can hog a system just like (or more than) Strigi, and this flew under everyone's radar.

3. I simply left akonadi_nepomuk_email_feeder index all the mail. After half an hour, akonadi_nepomuk_email_feeder seemed to finish, because there wasn't more mail to index, and my Virtuoso (hence, NEPOMUK) CPU usage went to the single digits and stayed there.

With Fedora the behavior was more straightforward, but similar. After no recreating resources, but simply using what I had, akonadi_nepomuk_email_feeder pushed my CPU to 70% out of 200%. After a while, all mail was indexed, and NEPOMUK CPU usage went to the single digits.

I filed a separate bug against akonadi_nepomuk_email_feeder (bug 249828) because that process doesn't suspend on batteries like Strigi does. Also, its interaction with Virtuoso and NEPOMUK should be monitored.

This also means that, for everyone affected, a spot-on workaround should be to remove the Nepomuk E-Mail Feeder resource from your Akonadi pool.