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

[E. Hakan Duran]

Hi Martin,

I ended up resetting kdepim as recommended by the kde website, which I cannot 
remember the address at the moment. What I essentially did was to rename the 
folders ~/.local/share/akonadi and ~/.config/akonadi to akonadi.old. Then all 
mail and calendar agents were gone but the identities were somehow retained 
(thankfully). I redefined all mail and calendar accounts afterwards, and set 
the size threshold to 32768 :). Of course it took a while to rebuild the 
database, but since then I am able to maintain the size of the folder 
file_db_data at 1.6 GB independent of the duration of akonadi staying on.

I have been using my ~ folder since fedora 15, i.e. about 6 years and although 
I don't have any evidence of file corruption I tend to think that certain 
subtle changes in config files etc. between versions of even the same flavor of 
linux may make programs act bizarre. For example, I had an untrusted 
certificate issue with my Citrix account form this same computer, and no matter 
how much I troubleshooted, I just couldn't get it work. Finally, letting 
Firefox recreating the ~/.mozilla folder solved everything :). So that was 
what inspired me to do this.

Thank you for sharing your solution with me. I am quite content at the moment, 
and although I would welcome a more responsive kdepim, it is functional enough 
for me to enjoy its customizibility. I know it is not possible, but I really 
wish I could make donations specifically to kdepim.

Will stay in touch. Thanks!

Hakan

On Friday, February 27, 2015 09:58:04 AM Martin Steigerwald wrote:
> 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 at merkaba:~/.local/share/akonadi> find file_db_data | wc -l
> 32
> 
> martin at merkaba:~/.local/share/akonadi#1> du -sh file_db_data
> 4,3M    file_db_data
> 
> Very large IMAP account from work:
> 
> ms at merkaba:~/.local/share/akonadi> find file_db_data | wc -l
> 2376
> ms at 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 at 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.
> 
> Ciao,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20150227/74b9b7ce/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users