Since updating from 15.1 to 15.2, Kmail has been extremely slow - 5 to 10 minutes - in reading email folders or moving messages. It seems to be an akonadi issue as system activity shows an akonadi_maildir_resource using 25% of cpu for long periods as the email folder contents are being retrieved. I have tried akonadictl fsck, akonadictl vacuum, and akonadictl restart as has been recommended for similar problems, but it seems to have no effect. Do I need to rebuild the akonadi database somehow and, if so, how do I do it?
Other than this, by the way, the update has worked like a charm.
Others may be able to assist more definitively than I can as I’m not yet using Leap 15.2 and don’t use kmail. Here’s a kde forum post from a long-running thread where a user described the “Steps for a longer lasting solution than akonadictl restart”.
Quit kmail and use akonadiconsole. Try restarting suspect agents. You may delete the indexer and add a new one. Consider cleaning the database. Remove stale entries.
mysql --socket=/run/user/1000/akonadi/mysql.socket
MariaDB (none)]> use akonadi;
MariaDB (none)]> delete from pimitemtable where remoteid is NULL;
MariaDB (none)]> quit
When running “akonadictl fsck”, the only RID related errors present should be as follows (with language related to your Locale):
Looking for dirty objects...
Collection "Search" (id: 1) has no RID.
Collection "OpenInvitations" (id: 519) has no RID.
Collection "DeclinedInvitations" (id: 520) has no RID.
Collection "Letzte Suche" (id: 1323) has no RID.
Found 4 collections without RID.
Found 0 items without RID.
Found 0 dirty items.
For systems with English language, “Letzte Suche” translates to “Last Search”.
Looking for rid-duplicates not matching the content mime-type of the parent collection
shouldn’t indicate any errors or warnings.
[HR][/HR]If you find any errors other than those listed above, then you should also inspect the Akonadi error logs located in “~/.local/share/akonadi/”.
If you find any “items without a RID” use MySql to clean up and move these items to “~/.local/share/akonadi/file_lost+found/” and, you can then reload these items back into the KDE PIM.
Remove the contents of “~/.local/share/akonadi/” only after you’ve done this.
Alternatively, archive all your e-Mail folders and export your KMail settings before you delete the Akonadi local-share and configuration directories.
As a general practice, you should occasionally archive your e-Mail directories and settings anyway …
I used Kmail for at least a decade before making the difficult decision to ditch it in favour of Thunderbird. Kmail has some very nice features, but seems to have an intractable bug which resulted in periods where akonadi (?) saturated the CPU, my patience eventually ran out, and I hit the power button to restart the system & stop akonadi. This bug seems well known and not likely to be fixed in the forseeable future. I’ve raised the issue before, see for example https://forums.opensuse.org/showthread.php/537567-Akonadi-saturating-the-CPU-100?highlight=kmail
Thunderbird is pretty good from a functional perspective, it’s reliable, and it has some nice add-ons such as enigmail, coloured folders, and email redirection. I managed to migrate a very large Kmail database without too much difficulty.
A response to the Bugzilla page recently added says that the problem has been fixed in QT 5.14 and it is unclear whether the fix will be backported to 5.12 which is used in Opensuse 15.2. This raises three questions:
Will the fix be backported for Opensuse 15.2 and, if so, what is the time frame?
Is there a repository with QT 5.14 for 15.2 which can be used to update to the newer QT version?
If so, would such an update have harmful repercussions for my system?
The problem is that nobody knows what the fix actually is so far.
Just some affected users reported that the problem seems to be gone after updating to Qt 5.14(.2, IIRC).
If somebody finds out what exactly the fix is, it might be possible to backport it (or not, if the changes are too intrusive, rely on other changes, …).
My guess: it’s not a simple bug in Qt < 5.14, but actually caused by some change in KDEPIM itself that happens to work fine on newer Qt releases, but not so much on older ones.
Is there a repository with QT 5.14 for 15.2 which can be used to update to the newer QT version?
Yes, but you have to upgrade all KDE packages as well, same as in previous versions.
(Actually it has 5.15.0 meanwhile, not 5.14 anymore )
If so, would such an update have harmful repercussions for my system?
Well, new versions bring new features and can introduce new bugs. Also the packages are more or less untested (at least before they get submitted to Tumbleweed).
But all in all it should be fine, as long as you do a full switch and not “forget” to update some packages.
Personally I’m using the additional KDE repos to always get the latest versions, since a looong time.
If you are worried about this bug, it probably would be better to wait with the upgrade though.
(at least if you are not willing to add/use the additional KDE repos too, with them the problem should not occur)
I am currently trying the postgres 11 and i have very frequent crashes during the database building. So it would mean that it does not depend on the database program but on kde/qt .
Has anyone a better info about that ?
Who managed to have a correctly runing kmail/akonadi with a normal quantity of email, more than 10,000 (i have about 100,000) ?
kmail runs here with default configuration. It easily deals with the 50.000 files. Search is really fast. Cpu load is negligible. You are beating the wrong horse.
Thank you for your answer, Karl.
So, you have the default opensuse 15.2 kmail runing without problems and with a large amount of mails. Do you ?
Which db manager do you use ?
I was wondering why akonadi/kmail is so slow.
So if it’s not due to big amount of mails (i have folders with more than 10,000 mails), where does this comes from ?
And why do some users (like bearymore and me) have this problems ? And some (like Karl) don’t ?
I did the akonadictl fsck, akonadictl vacuum and akonadictl restart method. No success.
I also checked if my old 2012 latop was the problem, but i use a recent ssd inside and i checked that the 4GB RAM is not fully used by the system.
Is this due to KDE/QT , really ? So why opensuse doesn’t officially update kde/qt ?
The i7-6700K is great, but the i3-4130 performs well too with kmail.
You will want to have your mail buffered:
erlangen:~ # free -h
total used free shared **buff/cache** available
Mem: 31Gi 2.2Gi 25Gi 338Mi **3.8Gi** 28Gi
Swap: 15Gi 0B 15Gi
erlangen:~ #
Big RAM isn’t a waste of money, but serves as an ultra fast disk. When performing folder operations kmail sometimes creates local copies of the mail termed “external files” and deletes them again when cleaning the cache. The notebook with the i5-8250U has one 8 GiB DDR4 and a 256 GB nvme drive. That works well too as does the i3-4130 / 2x8GiB DDR3 / 250 GB SSD 850 EVO.
)