Due to the CPU contention issue with Akonadi, I had to use this piece of advice: https://bugs.launchpad.net/ubuntu/+source/akonadi/+bug/909022/comments/7 This worked, and CPU use by Akonadi components is back to a tolerable level. However, after the Akonadi database rebuild finished, akonadi_nepomuk_feeder is still holding on to a lage amount of memory, as visible in the attached smaps file and pmap -x output. Reproducible: Didn't try Steps to Reproduce: 1. Get a decently sized mail collection of ~40000 mails with attachments or more. 2. Be forced to wipe Akonadi database due to unusability. 3. Have Nepomuk indexing enabled, you want to search all that mail. 4. Wait a long time for database rebuild to finish. Actual Results: akonadi_nepomuk_feeder now holds onto a lot of memory, most of it on its heap (anonymous, non-shared memory). Expected Results: akonadi_nepomuk_feeder should not have to keep all that memory, as the data is supposedly indexed and stored in virtuoso? Mail is stored in several seperate akonadi_imap_resource and a few pieces in a local mail folder. Reproducing tends to take about a day, which is why it was not done.
Created attachment 83137 [details] pmap -x output for akonadi_nepomuk_feeder
Created attachment 83138 [details] /proc/$pid/smap for akonadi_nepomuk_feeder
I can confirm. When indexing large amount of emails, the feeder is leaking memory. I've seen my feeder to get over 1GB of memory.
Confirmed. I can reproduce this in a small test case. The leak seems to be in the Akonadi libs. I'll bring this up during the PIM sprint and we can investigate.
The Nepomuk project is no longer maintained in KDE since 4.13. For email indexing, Baloo provided an Akonadi resource to index emails, contacts and events. Tags are now maintained by Akonadi itself.