Re: Akonadi dsaster

Daniel Vrátil <[email protected]> Fri, 14 Oct 2016 09:12:10 +0200
Newsgroups	gmane.comp.kde.users.pim
Organization	KDE
Message-ID	<49229855.ZaIGXMTXx2@mjollnir>
On Monday, October 10, 2016 10:12:42 AM CEST Michael Mol wrote:
> A *huge* chunk of this, for me, turned out to be in the abysmal MySQL
> configuration it defaults to. I posted about it on Google+ and on /r/kde
> several months ago. https://plus.google.com/+MichaelMolG/posts/HQQH6RHhLNw
> 
> I'll note my understanding of Akonadi has improved slightly since I wrote
> that; I wasn't able to find where Akonadi's MySQL configuration was kept, so
> I switched out to using a system mysqld.That's not necessary if you know
> where Akonadi sources its MySQL configuration from.
> 
> I'll also add that I'm syncing nearly a decade's worth of email from GMail
> into Akonadi, hundreds of thousands of emails. People without as much email
> history likely won't see the same kind of performance difficulties I do.
> 
> Here's the relevant excerpt:
> 
> Altogether, here are the changes I've made:
> 
> In my.cnf
<snip>

Oooo, this looks quite interesting, thanks.

The major problem with the default database configuration is to find the right 
balance. If you go too high, regular users who only have a gmail with a few 
emails with funny cat gifs and powerpoint presentations will complain that we 
use to much resources. On the other hand if we go too low, power users will 
complain that their 2 million emails from 10 years of kernel mailing list 
takes ages to load. Striking the right balance is hard.

There is a good point that we could probably increase all the default values a 
bit since the computers are generally better equipped nowadays that they were 
some 5 years ago, but again, we need to be rather conservative about that.

I would like to see some sort of a self-balancing configuration, where the 
database could "suggest" optimal settings based on long-time load and 
available hardware resources. That would magically solve the issue described 
above, but that's more of a day-dreaming :-)

Pablo made a good point elsewhere in this thread about the ridiculous amount 
of queries we do. I've added some more optimizations to master recently to 
speed up some things, but there's still a long way to go :(

Dan

> 
> On Friday, October 07, 2016 11:51:00 PM Anders Lund wrote:
> > Hi,
> > I am using kmail, because it is, still, by far the best mail client I
> > know.
> > But the akonadi backend is absolutely not well functioning. I have to
> > restart it daily, it often chokes. Even when running, it often makes kmail
> > mega slow. I can click on a message header, but instead of showing it,
> > kmails claims it is "retrieving folder contents". Not what I asked for...
> > 
> > Akonadi also appears to choke without any sign of that happening, apart
> > from the lack of new mail. Then a restart is required.
> > 
> > But as I said, apart from that I really like kmail!
> > 
> > My 2c,
> > Anders
> > 
> > onsdag den 5. oktober 2016 09.19.19 CEST skrev O. Sinclair:
> > > It is, and sorry for rant, but it is quite simply embarrasing that K9
> > > mail on my android phone works better than KMail 5.x
> > > 
> > > Akonadi was/is probably a nice concept but crash in this version not
> > > only on a daily but basically hourly basis. Noone seems to know just why
> > > the database thing goes bonkers all the time.
> > > 
> > > I am dead tired of "akonadictl stop", "akondictl fsck" and "akonadictl
> > > start". Then wait while the mails from IMAP are downloaded once again
> > > though it is set to "offline IMAP".
> > > 
> > > Can we "deAkonadi" KMail?
> > > 
> > > Regards, Sinclair


-- 
Daniel Vrátil
www.dvratil.cz | [email protected]
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
signature.asc (application/pgp-signature, 819 B)