Akonadi database (war: Re: KDEPIM 17.08: The whole thing works)
Hello Frank,
Frank Mehnert - 17.11.17, 09:17:
> Martin,
>
> thank you for sharing your experiences!
>
> Regarding the database optimization: Would it be possible to remove
> the complete database in certain cases? AFAIR, the Akonadi DB does
> not store the messages itself, it only stores indexing information,
> probably also flags / message tags etc...
Anything is possible.
Will you do it? The current KDEPIM developers will not do it. And I am quite
certain I can say this here from what I remember of past discussions on this
matter. They replied to this question countless of times.
Akonadi caches messages, but it does not store them permanently. This has been
addressed several times in various places as well already.
As far as I understand the changes in indexing that Daniel works on will mean
that for indexing the mails, contacts, events, whatever do not need to go into
the Akonadi database temporarily anymore.
I totally get the skepticism about the database, but a database does not need
to be an issue. Zimbra uses a MySQL database too and its blazingly fast even
with 450000+ mails in *one* folder. However what I dislike a bit is that
Akonadi uses a database, yet does not really totally free the user from
handling it. Anyone with a larger set of mails needs to tune the MySQL
database as I described here and on kdepim-users before… wait… maybe that is
the performance drop I currently see in Akonadi/KDEPIM 17.08
Yep, the upgrade undid my optimizations:
-innodb_buffer_pool_size=1024M
+innodb_buffer_pool_size=128M
(this is already more than the 64 MiB it used initially)
# Buffer size used to write to the log files on disk (default:1M for builtin,
8M for plugin)
# larger values means less I/O
-innodb_log_buffer_size=32M
+innodb_log_buffer_size=1M
(and yes, I think I still have an bug report this open in upstream bugtracker)
I suggest anyone with a large body of mails and stuff to run mysqltuner.pl on
the database and tune it.
I will redo the tuning now against the newly installed database configuration.
I think this will fix the performance drop in mail filtering I perceived.
So all that is my main critique regarding the database: The user should not be
required to do things like this. So either Akonadi could handle MySQL or
PostgreSQL with high performance *all by itself*, so maybe, just maybe,
another database which does not require the user to be a part-time database
admin would be in order.
Another critique of mine is: Akonadi 16.04 at least did way to much and was
still not really optimized as much as it can regarding database queries.
KDEPIM developers are application developers, not really database experts, it
appears to me. Additionally Akonadi 16.04 did to much on mail filtering with
local maildirs anyway: It synchronized each folder after each few mails it
placed there. Yet, no one else is changing those maildirs, it moved the mails,
so why check in the first place? Synchronizing means it lists the directory
contents and synchronizes it with the information it has in the database. Also
with IMAP in 16.04 the folder synchronisation happened much too often. Even
just after deleting a few mails.
Actually I think a kind of database is needed. Going back to pre-akonadi times
of using index files within KMail itself does not really make sense to me. The
probable Akonadi replacement Sink that Kube mail client uses, also uses a
database. I am not completely sure, but I think its LMDB, the Lightning Memory
Database of the OpenLDAP project. It may be something else tough. But I would
not hold my breath on Sink replacing Akonadi for KDEPIM anytime soon. Its the
implementation that at least with 16.04 left a lot to be desired, not the
usage of the database itself that is the main issue here.
However all of that is nothing that makes sense to discuss here – as that are
upstream matters. You may try to discuss this with upstream developers, but be
prepared that they may not like the database or not discussion once again.
This is really a question that I have seen *a ton of times* in various places.
This is a touchy subject with upstream developers I think.
I kindly ask you to drop the discussion on this matter here, as it would just
be a waste of time here on this list. Thank you.
Even if you go on… I may not reply anymore – I took a lot of time for this
detailed reply already. See kdepim-users and kde-pim upstream mailing lists as
well as various upstream bug reports or even discussions in debian-kde for
tons of discussions on this matter. Anything is there, including the hints
about optimizing the database.
Yes, I am a bit annoyed that you brought the database or not question up once
again. It has been discussed to death already. However, I also understand that
there is no central place for all of the information I provided or hinted at
above. I think at least the database optimization should go into upstream
wiki, but I never took the time to do it. I kindly invite you or any other
user to distill information on the list onto a wiki page. I would happily
review with page.
Thanks,
--
Martin
Reply to: