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. With the SizeTreshold=32768 change I get a nice improvement for my work IMAP account on the laptop (the one I set to download all mails offline). Before: ms@merkaba:~/.local/share/akonadi> du -sch db_data/akonadi/* | sort -rh | head -10 2,8G insgesamt 2,6G db_data/akonadi/parttable.ibd 245M db_data/akonadi/pimitemtable.ibd 13M db_data/akonadi/pimitemflagrelation.ibd 248K db_data/akonadi/collectionattributetable.ibd 200K db_data/akonadi/collectiontable.ibd 136K db_data/akonadi/tagtable.ibd 120K db_data/akonadi/tagtypetable.ibd 120K db_data/akonadi/tagremoteidresourcerelationtable.ibd 120K db_data/akonadi/tagattributetable.ibd ms@merkaba:~/.local/share/akonadi> find file_db_data | wc -l 524917 ms@merkaba:~/.local/share/akonadi#130> /usr/bin/time -v du -sch file_db_data 7,0G file_db_data 7,0G insgesamt Command being timed: "du -sch file_db_data" User time (seconds): 2.14 System time (seconds): 95.93 Percent of CPU this job got: 29% Elapsed (wall clock) time (h:mm:ss or m:ss): 5:35.47 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 33444 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 1 Minor (reclaiming a frame) page faults: 8079 Voluntary context switches: 667562 Involuntary context switches: 60715 Swaps: 0 File system inputs: 31509216 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 After the change and akonadictl fsck: ms@merkaba:~/.local/share/akonadi> find file_db_data | wc -l ; du -sch db_data/akonadi/* | sort -rh | head -10 27 7,5G insgesamt 7,3G db_data/akonadi/parttable.ibd 245M db_data/akonadi/pimitemtable.ibd 13M db_data/akonadi/pimitemflagrelation.ibd 248K db_data/akonadi/collectionattributetable.ibd 200K db_data/akonadi/collectiontable.ibd 136K db_data/akonadi/tagtable.ibd 120K db_data/akonadi/tagtypetable.ibd 120K db_data/akonadi/tagremoteidresourcerelationtable.ibd 120K db_data/akonadi/tagattributetable.ibd Yep, thats 27 files, instead of >500000 (after just a week of the last fsck, which reduced to about 500000 files, from 650000+). After a nice vacuuming I even get: ms@merkaba:~/.local/share/akonadi> find file_db_data | wc -l ; du -sch db_data/akonadi/* | sort -rh | head -10 27 6,5G insgesamt 6,2G db_data/akonadi/parttable.ibd 245M db_data/akonadi/pimitemtable.ibd 13M db_data/akonadi/pimitemflagrelation.ibd 248K db_data/akonadi/collectionattributetable.ibd 200K db_data/akonadi/collectiontable.ibd 136K db_data/akonadi/tagtable.ibd 120K db_data/akonadi/tagtypetable.ibd 120K db_data/akonadi/tagremoteidresourcerelationtable.ibd 120K db_data/akonadi/tagattributetable.ibd merkaba:/home/ms/.local/share/akonadi> du -sh file_db_data 6,5M file_db_data I definitely prefer this over the original situation. Original was 2,8 GiB DB + 7 GiB file_db_local. Now is 6,5 GiB DB + 6,5 file_db_local and more than 524000 files less to consider for rsync and our enterprise backup software. Let's see whether it brings an performance enhancement, but for now I like this. Thanks, -- 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.