Goodbye for now, kmail
Martin Steigerwald
martin at lichtvoll.de
Fri May 5 15:45:08 BST 2017
Pablo Sanchez - 05.05.17, 09:06:
> [ Comments below, in-line ]
>
> On Fri, 05 May 2017 17:57:39 +0530, Vishnu V. Krishnan wrote:
> >> You can use Akonadi with PostgreSQL instead of MariaDB. Not sure whether
> >> that helps w.r.t. systemd. Use the search engine of your choice for
> >> instructions.
> >
> > Thanks for pointing it out. Upon looking into it, I don't think I'll be
> > able to get rid of MariaDB, because in all the distros I use (Arch-based
> > stuff), Akonadi is built with MariaDB as a hard-dep. Looks like I'll have
> > to build it myself to change this, or use a distro like Gentoo.
> I don't believe the DBMS engine is the problem. IIRC, we'd be sending
> the same extraordinary number of SQL calls.
Zimbra is an example based on MySQL/MariaDB + Lucene that works really nice
with million of mails – and even more, I am not sure whether thats still the
case, but at least it was the backend for Yahoo Mail and that tells something.
So no, the DBMS is not the issue … but I think it needs to be automatically
configured and managed as I would require no ordinary user to be a database
admin as well…
I currently see the following issues:
- Akonadi does needless work – like to frequent folder and too expensive
synchronisations (on IMAP after every few mails you delete). It requests all
DB entries for the collection it synchronizes to compare what is stored in
backend storage like IMAP or local Maildir. For local maildir I would like to
disable automatic folder synchronization *completely* cause I know that
Akonadi Maildir is the only user of it, yet it checks frequently whether the
million of mail files is still there.
- Akonadi does more needless work: When you moving a folder from one parent
folder to another parent folder within a local Maildir resource it first
creates the new folder, then copies all mails, then deletes it from the source
folder, essentially moving them and then deletes the source folder… instead of
just *renaming* the folder.
- Akonadi does more needless work: I reported several other bug reports.
- Akonadi has no notion of multitasking and background tasks – a folder
synchronisation blocks interactive user requests by kmail.
- Akonadi does not auto-tune MySQL performance settings like InnoDB buffer
pool size with is ridiculously low after anything than a few mails. A too low
InnoDB buffer pool size leads to additional file I/O accesses.
Thing is: All of these issues are known since years. And while Dan, Milan and
others did impressive performance optimizations these basic issues are all
still unfixed.
And as such, while KMail and Akonadi works well enough for me after raising
InnoDB buffer pool size to 1 GiB, and believe me I can easily notice when on
an Akonadi upgrade it gets downgraded to 80 MiB again…, I can fully understand
the massive frustration with it. Usually I have retrieving folder contents or
mail notifications only for a few seconeds, but I am still seeing this. And
this is on Dual SSD BTRFS RAID 1 with surely fast enough Sandybridge ThinkPad.
So while I believe that creating a solution that works and uses an DBMS is
possible… for some reason be it lack of developer time and/or design issues
within Akonadi, Akonadi still is not that solution. And thats after more than
5 years of introducing it. So I perfectly can understand the frustration and I
certainly also can understand the arguments to ditch Akonadi completely or
replace it by something else like Sink. However Sink probably did not prove
itself in the scenarios KDEPIM would need it for.
Ciao,
--
Martin
More information about the kdepim-users
mailing list