[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