mikemol at gmail.com
Mon Oct 10 15:12:42 BST 2016
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:
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
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:
> 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,
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: This is a digitally signed message part.
More information about the kdepim-users