[Kde-pim] Experiences with current Akonadi perf improvements

Martin Steigerwald Martin at lichtvoll.de
Thu Dec 18 12:03:42 GMT 2014


Hello!

I have been testing c733429f4fa9696fb027ddc946e54f6bbb68deaf from 1.13 branch 
of Akonadi and just as a short heads up:

It works nicely.

I see lot less load on MySQL.

By magnitudes.

So thats great!

Thank you.


Yet it doesn´t solve some other existing issues with current Akonadi:

What I still see at a time is that Akonadi doesn´t respond to KMail in a 
timely manner, up to the point that KMail even looses the connection to 
Akonadi and then both sit there doing nothing anymore unless I restart KMail. 
I would like to easily see what Akonadi is doing at that time. Maybe you have 
some ideas on how I can see it.

I see akonadi maildir resource with high load then, sometimes MySQL at around 
100-150%, but more often just maildir resource and akonadiserver. It may be 
synchronizing folders at that time, I sometimes don´t know exactly, cause 
often Akonadiconsole doesn´t provide any useful feedback on what the resource 
is doing at the moment. Sometimes I see its synchronizing a folder, sometimes 
I see no info in Akonadiconsole while it still hogs a CPU core for a while.

I remember that I optimized the maildir scan by stopping it from sorting the 
maildir when trying to list it. Yet I still wonder why on earth it 
synchronizes at all:  And in what circumstances. If Akonadi stored the files 
there, they will be there tomorrow as well – thats the whole purpose a 
filesystem is about. So during runtime of Akonadi it has inotify on them should 
another app add a mail there, so there is no business to *ever* synchronize a 
maildir at all during runtime of Akonadi, except on the first time a folder is 
accessed after startup of Akonadi where it may check whether an app dropped a 
mail there while Akonadi was stopped.

I hope in the next time I have some more time to actually at least try to 
diagnose the KMail Akonadi connection breakup. Its the most annoying thing for 
me currently as it happens one or two times a day at least usually.

So thats important points for Akonadi Next IMHO:

1) Provide good progress report on what each resource is doing. A user who 
sees a process hogging a CPU core without *any* feedback as to *why* will 
likely get dissatisfied with it. Of course, if that kind of thing doesn´t 
happen with Akonadi Next anymore, this point could be skipped. Or progress 
report made less often in order to not harm the performance by progress 
reporting.

2) Do only work that is *necessary*. Be as lazy as you can get. As I suspected 
for a long time and as recent optimization work has shown: Current Akonadi did 
a lot of work that wasn´t necessary. And I think in case of folder 
synchronization it still does useless work.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list