Re: Work-around to issues with Akonadi file based caching (was: Re: rant)

Martin Steigerwald <[email protected]>
Newsgroups gmane.comp.kde.users.pim
Message-ID <1631205.Agz9sbGSHg@merkaba>
Am Freitag, 27. Februar 2015, 09:58:04 schrieb Martin Steigerwald:
> Hakan,
> 
> Am Sonntag, 15. Februar 2015, 17:19:45 schrieb E. Hakan Duran:
> > On Friday, February 13, 2015 10:34:28 AM Martin Steigerwald wrote:
> > > ...
> > > The SizeThreshold thing helped me with that. But have caution: This
> > > is
> > > no official recommendation of Akonadi developers. Still, it gave me
> > > a
> > > good improvement with performance and latency *and* seemed to have
> > > solved the insane amount of file and data in file_db_data issue for
> > > me. Or at least it worked around it successfully.
> > >
> > >...
> > 
> > Thank you once again Martin. I made the changes you recommended. I
> > think it feels a little more responsive now, but I have to use it a
> > few more days to make a more objective call.
> > 
> > I still notice a growing file_db_data folder, proportional to the time
> > akonadi is left on. I am considering to delete everything and start
> > from scratch but I have so many accounts (e-mail, personal and work
> > calendars, etc.) it feels like a waste of my time at the moment.
> > Instead, I will keep turning akonadi off as soon as I check and reply
> > to my emails, and then run fsck afterwards to get rid of the mess it
> > generated until I have more time for the revamp or I am truly pissed
> > 
> > :).
> 
> so far this change works for me.
> 
> Several POP3 accounts, one very large, all in one maildir, and a 30-day
> limited IMAP account:
> 
> martin@merkaba:~/.local/share/akonadi> find file_db_data | wc -l
> 32
> 
> martin@merkaba:~/.local/share/akonadi#1> du -sh file_db_data
> 4,3M    file_db_data
> 
> Very large IMAP account from work:
> 
> ms@merkaba:~/.local/share/akonadi> find file_db_data | wc -l
> 2376
> ms@merkaba:~/.local/share/akonadi> du -sh file_db_data
> 663M    file_db_data
> 
> 
> Hmmm, yikes. Its large in there, but at least not very many files. And
> well, it seems that are mails with larger attachment that Akonadi caches
> there:
> 
> ms@merkaba:~/.local/share/akonadi> du -sh file_db_data/* | sort -rh |
> head 11M     file_db_data/4735240_r1
> 11M     file_db_data/4735240_r0
> 11M     file_db_data/4735239_r1
> 11M     file_db_data/4735239_r0
> 9,4M    file_db_data/4734016_r1
> 9,4M    file_db_data/4734016_r0
> 9,3M    file_db_data/4731257_r0
> 8,6M    file_db_data/4731853_r1
> 8,6M    file_db_data/4731853_r0
> 7,2M    file_db_data/4732214_r1
> 
> And as I think I set the account to offline caching that even makes
> sense.
> 
> 
> Well all it comes down to is: If you have lots of mails that are larger
> than 32 KiB the change won´t help. You may try with an even larger
> SizeThreshhold, but as I did never test it and no of no one else who
> did, I can´t say whether it would work. Also I don´t know the maximum
> limit for SizeThreshold, I don´t know the limit of MySQL for storing
> these blobs in the database.
> 
> All I see here is that SizeThreshold=32768 works okay here.
> 
> 
> These figures are weeks after the change and I didn´t do any manual
> optimization aka akonadictl fsck or akonadictl vacuum. I may try it on
> the work account next week to see whether Akonadi again lost track of
> some files.

This still seems to work for me:

Since my work-around with SizeThreshold=32768 on my private setup:

martin@merkaba:~/.local/share/akonadi> find file_db_data | wc -l
33
martin@merkaba:~/.local/share/akonadi> du -sh file_db_data 
4,4M    file_db_data
martin@merkaba:~/.local/share/akonadi> du -sh file_db_data/* | sort -rh | 
head -10
896K    file_db_data/2815963_r0
584K    file_db_data/2630687_r0
452K    file_db_data/2630658_r0
448K    file_db_data/2630655_r0
368K    file_db_data/2488539_r0
164K    file_db_data/2758167_r0
152K    file_db_data/2488220_r0
120K    file_db_data/2488152_r0
104K    file_db_data/2565672_r0
100K    file_db_data/2943194_r0


And on my laptop work setup:

ms@merkaba:~/.local/share/akonadi> find file_db_data | wc -l
2442

ms@merkaba:~/.local/share/akonadi> du -sh file_db_data 
703M    file_db_data

still quite much, but I set the account to offline caching and I think it 
cached mails with larger attachments:

ms@merkaba:~/.local/share/akonadi> du -sh file_db_data/* | sort -rh | head 
-10
11M     file_db_data/4735240_r1
11M     file_db_data/4735240_r0
11M     file_db_data/4735239_r1
11M     file_db_data/4735239_r0
9,4M    file_db_data/4734016_r1
9,4M    file_db_data/4734016_r0
9,3M    file_db_data/4731257_r0
8,6M    file_db_data/4731853_r2
8,6M    file_db_data/4731853_r1
8,6M    file_db_data/4731853_r0

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.