Am Freitag, 23. Januar 2015, 07:17:13 schrieb Dmitry Smirnov: > Hi Brad, > > On Fri, 2 Jan 2015 11:28:53 Brad Alexander wrote: > > Can anyone suggest a fix or workaround other than starting akonadi every 5 > > - 10 minutes? > > I had similar problem when akonadi accumulated nearly 2 million files in the > > ~/.local/share/akonadi/file_db_data > > Here is what helped me: > > * Set "SizeThreshold=32768" in "~/.config/akonadi/akonadiserverrc" > (default is 4096). > > * Run "akonadictl fsck" which moved unreferenced files to > "~/.local/share/akonadi/file_lost+found" (safe to remove) > and gobbled files smaller than 32768 bytes from "file_db_data" > into database. > > The above procedure dramatically improved kmail performance and response > time. > > To optimise further you can check MySQL configuration in > > ~/.config/akonadi/mysql-local.conf > ~/.local/share/akonadi/mysql.conf > > and bump "innodb_buffer_pool_size" and/or other relevant parameters. Thank you very much, I will try this. And see whether it helps with these upstream bugs: [Akonadi] [Bug 338402] File system cache is inneficient : too many file per directory Bug 332013 - NFS with NetApp FAS: please split payload files in file_db_data into several directories to avoid reaching maxdirsize limit on Ontap / WAFL filesystem Bug 341884 - dozens of duplicate mails in ~/.local/share/akonadi/file_db_data I bet it may help with the first two, but third one might be another bug. Right now locally after the last akonadictl fsck I only have from 4600 after the fsck to 4900 files now in my private setup with still is mostly POP3 just a 30 day limited IMAP for the Fairphone and as a backup when I accidentally mess up with something locally. It really seems Akonadi is more snappy since the fsck. I have lots more files in there. I also bumped innodb_buffer_pool_size but didn´t see that much of a change, what helped most with MySQL load is to use Akonadi git 1.13 branch with database performance improvement. I now implemented the treshold size change you suggested and did another fsck and vacuum. I will do these on my work account as well which is a huge IMAP account hosted on Exchange which is a good performance challenge. My work account on the laptop had 650000 => 500000 files after the fsck, I bet upping the treshold will help here greatly. On the workstation I need to look, but it was the one which triggered bug 332013. Maybe the size treshold default is something that could be changed to mitigate some of the performance issues of Akonadi on the short term. While I still think its not RC bug, it is very annoying. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.