Akonadi dsaster

[Michael Mol]

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

innodb_buffer_pool_size = 1024M # I have 16GB of RAM. I can spare a gig to keep 
more of Akonadi's working set in memory.
innodb_buffer_pool_instances = 16 # Akonadi, in my use case, tends to be 
heavily concurrent; I've got multiple mail accounts, calendars and consuming 
applications.
innodb_flush_log_at_trx_commit = 2 # Akonadi is fundamentally a cache, not the 
data store itself, so we can tolerate a few seconds' transaction loss; it'll 
get cleaned up on a subsequent sync, anyway. And it'll only matter if I lose 
power during a sync when I'm actually seeing new data.
innodb_flush_method=O_DIRECT # Bypass the filesystem layer page cache; I'm 
dedicating 1GB of memory to keeping MySQL data in RAM...I don't need a second 
copy of that data pushing other files and applications out of memory.

binlog_format=mixed # This is actually a KDE-specified thing, but wasn't part 
of my systemwide config, so I added it.

skip-innodb_doublewrite # My filesystem is ext4 with data=journal, so this is 
safe enough, barring filesystem bugs.

query_cache_type=ON # Why, yes, we want the query cache enabled; Akonadi is a 
heavy concurrent-read system.
query_cache_size=256M # I have 16GB of RAM. I can spare some memory.
thread_cache_size=256 # Akonadi makes a lot of connections, and thread 
creation adds up.

Then I needed to modify some sysctl values, as, after the MySQL changes, the 
rest of the system became unusably slow:

vm.dirty_background_bytes = 1048576 # As soon as we have 1MB of data (not 
MySQL data, but other applications) waiting to get written to disk from non-
synchronous write() calls, start trying to flush the data.
vm.dirty_bytes = 16777216 # As soon as we have 16MB of data (not MySQL data, 
but other applications) waiting to get written to disk from non-synchronous 
write() calls, halt all further write() attempts and flush the buffered data to 
disk before continuing.

That 1MB / 16MB limit set, in reality, will slow applications fundamental 
throughput down, but it provides an indirect guarantee on how long it will 
take before data hits disk. When the default limits are around 20% of RAM, 
which on a 16GB system is about 3GB, you discover how much it sucks for your 
desktop to be completely unresponsive for a minute or so at a time. (No, I do 
not have a fast disk. And any of you with SSDs out there, I might make 
dirty_background_bytes something like 16MB, and dirty_bytes something like 
32MB, to let the kernel do a lot more write-combining, owing to how data is 
organized on an SSD.)


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
-- 
:wq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20161010/36eb6c53/attachment.sig>