Re: Goodbye for now, kmail

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