facts about resource usage of an empty and unused Akonadi (was: Re: disable akonadi)
Martin Steigerwald
martin at lichtvoll.de
Mon Sep 3 09:20:04 BST 2018
Hello Draciron.
Draciron Smith - 03.09.18, 08:15:
> The thread is about shutting down Akondi and why people want to do so.
Right.
> And it appears that a lot of people have to shut down Akondi because
> of performance reasons. Not just from this thread. A quick google
There are at least two use cases to separate:
1) Users who use KDEPIM and Akonadi. I agree that there are performance
issues for some of the *users* of Akonadi.
2) Users who do not use KDEPIM and Akonadi. I do not agree that an empty
and unused Akonadi does use a lot of resources by todays standards of
computing power.
The performance impact for the second group of users is quite low. A claim
which is easy to backup with numbers. I won´t take the time, cause my Akonadi
is not empty and I´d need to measure with a new user. But I invite you to
proof otherwise to me (using smemstat to measure). Unless you have 2 GiB
of RAM or less, I´d recommend not to bother with it. An empty and unused
Akonadi just sits there, doing nothing after startup. If it is is still
using up a lot of CPU even tough you do not use it, I consider that to be a
bug I´d recommend you report.
Okay, what gives, I take the time to debunk myths. I asked for numbers,
so here you have the backup of my claim:
Akonadi´s memory usage a few minutes after it has been started up:
% smemstat | head -1 ; smemstat | egrep "akonadi|mysql"
PID Swap USS PSS RSS D User Command
22020 0,0 B 58,1 M 60,2 M 66,9 M martin2 /usr/sbin/mysqld
22074 0,0 B 19,2 M 26,6 M 93,8 M martin2 /usr/bin/akonadi_mailfilter_agent
22064 0,0 B 18,8 M 26,0 M 91,4 M martin2 /usr/bin/akonadi_archivemail_agent
22082 0,0 B 18,7 M 25,5 M 89,8 M martin2 /usr/bin/akonadi_sendlater_agent
22008 0,0 B 13,3 M 15,0 M 42,1 M martin2 /usr/bin/akonadiserver
22070 0,0 B 6516,0 K 7878,0 K 50,0 M martin2 /usr/bin/akonadi_notes_agent
22079 0,0 B 6072,0 K 7589,0 K 47,7 M martin2 /usr/bin/akonadi_indexing_agent
22083 0,0 B 5572,0 K 6856,0 K 48,9 M martin2 /usr/bin/akonadi_newmailnotifier_agent
22167 0,0 B 5584,0 K 6807,0 K 46,5 M martin2 /usr/bin/akonadi_ical_resource
22065 0,0 B 5480,0 K 6418,0 K 45,8 M martin2 /usr/bin/akonadi_followupreminder_agent
22072 0,0 B 5368,0 K 6393,0 K 45,3 M martin2 /usr/bin/akonadi_maildispatcher_agent
22119 0,0 B 5100,0 K 5963,0 K 44,0 M martin2 /usr/bin/akonadi_birthdays_resource
22174 0,0 B 4812,0 K 5746,0 K 44,0 M martin2 /usr/bin/akonadi_akonotes_resource
22152 0,0 B 4832,0 K 5740,0 K 43,9 M martin2 /usr/bin/akonadi_maildir_resource
22161 0,0 B 4760,0 K 5625,0 K 43,4 M martin2 /usr/bin/akonadi_contacts_resource
22062 0,0 B 4784,0 K 5595,0 K 43,0 M martin2 /usr/bin/akonadi_migration_agent
22004 0,0 B 4868,0 K 5483,0 K 38,2 M martin2 /usr/bin/akonadi_control
A good part is mysql with 58,1 MiB Unique Set Size. Then you have those
Akonadi processes most using below 7 MiB each. Now tell me how this would
be going to be an issue for machines with 4 GiB RAM or more? It may not
even be that much of an issue for machines with 2 GiB RAM especially when
you switch to SQLite3.
Akonadi also shows how far off RSS values can be as those processes share
a lot of code in form of shared objects.
CPU time used since startup about 20 minutes ago (started 9:19,
Sandybridge i5 on ThinkPad T520):
% pidstat 0 | head -3 | tail +3 ; pidstat 0 | egrep "[a]konadi|[m]ysql" | grep 1001
09:38:54 UID PID %usr %system %guest %wait %CPU CPU Command
09:38:54 1001 22004 0,00 0,00 0,00 0,00 0,00 3 akonadi_control
09:38:54 1001 22008 0,00 0,00 0,00 0,00 0,00 2 akonadiserver
09:38:54 1001 22020 0,00 0,00 0,00 0,00 0,00 3 mysqld
09:38:54 1001 22062 0,00 0,00 0,00 0,00 0,00 1 akonadi_migrati
09:38:54 1001 22064 0,00 0,00 0,00 0,00 0,00 0 akonadi_archive
09:38:54 1001 22065 0,00 0,00 0,00 0,00 0,00 2 akonadi_followu
09:38:54 1001 22070 0,00 0,00 0,00 0,00 0,00 1 akonadi_notes_a
09:38:54 1001 22072 0,00 0,00 0,00 0,00 0,00 0 akonadi_maildis
09:38:54 1001 22074 0,00 0,00 0,00 0,00 0,00 0 akonadi_mailfil
09:38:54 1001 22079 0,00 0,00 0,00 0,00 0,00 3 akonadi_indexin
09:38:54 1001 22082 0,00 0,00 0,00 0,00 0,00 0 akonadi_sendlat
09:38:54 1001 22083 0,00 0,00 0,00 0,00 0,00 2 akonadi_newmail
09:38:54 1001 22119 0,00 0,00 0,00 0,00 0,00 1 akonadi_birthda
09:38:54 1001 22152 0,00 0,00 0,00 0,00 0,00 1 akonadi_maildir
09:38:54 1001 22161 0,00 0,00 0,00 0,00 0,00 3 akonadi_contact
09:38:54 1001 22167 0,00 0,00 0,00 0,00 0,00 3 akonadi_ical_re
09:38:54 1001 22174 0,00 0,00 0,00 0,00 0,00 2 akonadi_akonote
Almost none. ps aux reports 2 seconds for starting up mysqld.
Disk usage (should be since startup according to manpage of pidstat, but
that does not appear so, at least mysqld did create the database):
% pidstat -d 0 | head -3 | tail +3 ; pidstat 0 | egrep "[a]konadi|[m]ysql" | grep 1001
09:41:05 UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
09:41:05 1001 22004 0,00 0,00 0,00 0,00 0,00 3 akonadi_control
09:41:05 1001 22008 0,00 0,00 0,00 0,00 0,00 0 akonadiserver
09:41:05 1001 22020 0,00 0,00 0,00 0,00 0,00 3 mysqld
09:41:05 1001 22062 0,00 0,00 0,00 0,00 0,00 1 akonadi_migrati
09:41:05 1001 22064 0,00 0,00 0,00 0,00 0,00 0 akonadi_archive
09:41:05 1001 22065 0,00 0,00 0,00 0,00 0,00 0 akonadi_followu
09:41:05 1001 22070 0,00 0,00 0,00 0,00 0,00 1 akonadi_notes_a
09:41:05 1001 22072 0,00 0,00 0,00 0,00 0,00 3 akonadi_maildis
09:41:05 1001 22074 0,00 0,00 0,00 0,00 0,00 0 akonadi_mailfil
09:41:05 1001 22079 0,00 0,00 0,00 0,00 0,00 3 akonadi_indexin
09:41:05 1001 22082 0,00 0,00 0,00 0,00 0,00 0 akonadi_sendlat
09:41:05 1001 22083 0,00 0,00 0,00 0,00 0,00 2 akonadi_newmail
09:41:05 1001 22119 0,00 0,00 0,00 0,00 0,00 1 akonadi_birthda
09:41:05 1001 22152 0,00 0,00 0,00 0,00 0,00 1 akonadi_maildir
09:41:05 1001 22161 0,00 0,00 0,00 0,00 0,00 3 akonadi_contact
09:41:05 1001 22167 0,00 0,00 0,00 0,00 0,00 3 akonadi_ical_re
09:41:05 1001 22174 0,00 0,00 0,00 0,00 0,00 2 akonadi_akonote
Disk capacity usage:
% du -sh ~/.local/share/akonadi
143M /home/martin2/.local/share/akonadi
+ some configuration and resource change status files.
You may switch to SQLite by just removing MySQL and PostgreSQL backends.
Or with a configuration option:
[%General]
Driver=QSQLITE
Memory usage:
% smemstat | head -1 ; smemstat | egrep "akonadi|mysql"
PID Swap USS PSS RSS D User Command
23667 0,0 B 19,2 M 26,7 M 93,8 M martin2 /usr/bin/akonadi_mailfilter_agent
23657 0,0 B 18,6 M 25,8 M 90,8 M martin2 /usr/bin/akonadi_archivemail_agent
23673 0,0 B 18,8 M 25,4 M 89,0 M martin2 /usr/bin/akonadi_sendlater_agent
23647 0,0 B 10,5 M 11,7 M 37,9 M martin2 /usr/bin/akonadiserver
23672 0,0 B 6488,0 K 7862,0 K 50,0 M martin2 /usr/bin/akonadi_notes_agent
23662 0,0 B 6012,0 K 7425,0 K 47,1 M martin2 /usr/bin/akonadi_indexing_agent
23670 0,0 B 5364,0 K 6621,0 K 48,4 M martin2 /usr/bin/akonadi_newmailnotifier_agent
23660 0,0 B 5440,0 K 6436,0 K 46,0 M martin2 /usr/bin/akonadi_followupreminder_agent
23665 0,0 B 5364,0 K 6358,0 K 44,9 M martin2 /usr/bin/akonadi_maildispatcher_agent
23661 0,0 B 5136,0 K 6255,0 K 45,1 M martin2 /usr/bin/akonadi_ical_resource
23658 0,0 B 4948,0 K 5814,0 K 44,1 M martin2 /usr/bin/akonadi_birthdays_resource
23664 0,0 B 4792,0 K 5663,0 K 43,6 M martin2 /usr/bin/akonadi_maildir_resource
23656 0,0 B 4760,0 K 5659,0 K 43,7 M martin2 /usr/bin/akonadi_akonotes_resource
23668 0,0 B 4752,0 K 5553,0 K 42,4 M martin2 /usr/bin/akonadi_migration_agent
23659 0,0 B 4656,0 K 5517,0 K 42,7 M martin2 /usr/bin/akonadi_contacts_resource
23644 0,0 B 4840,0 K 5462,0 K 38,0 M martin2 /usr/bin/akonadi_control
Disk capacity usage:
% du -sh ~/.local/share/akonadi
964K /home/martin2/.local/share/akonadi
% ls -lh ~/.local/share/akonadi/akonadi.db
-rw-r--r-- 1 martin2 martin2 4,0K Sep 3 09:45 /home/martin2/.local/share/akonadi/akonadi.db
+ some configuration and resource change status files.
I skip CPU usage and disk utilization measurements.
But for CPU time on startup:
ps aux reports a TIME of 0:00 for all processes. So none of the Akonadi
processes take more than one second to startup.
So can we be done about discussion of performance impact of empty and
unused Akonadi server already? Especially when switching to SQLite
backend discussing the performance impact of an empty and unused
is much ado about nothing¹. There is really (almost) nothing to see here.
[1] https://en.wikipedia.org/wiki/Much_Ado_About_Nothing
Even with just 2 GiB of RAM the Linux kernel will swap out the memory
used by Akonadi if need be and mostly be done with it.
If you still bother, an easy way to disable Akonadi might be to move
/usr/share/dbus-1/services/org.freedesktop.Akonadi.Control.service
out of the way, or probably "akonadictl", or well whatever starts Akonadi
once a widget or applications accesses it. I do not know for sure, as
I never bothered with disabling Akonadi. But with some trial and error
this should be easy enough to find.
Would it be nice to be able to disable it with a configuration option in
Systemsettings? Sure. Will KDEPIM developers implement this: Probably
not from what I heard so far. But you can open a bug report and aim at
providing a good reason for such a configuration option. In my oppinion:
if the user does not use something, it would be nice to be able to skip
even starting it. I totally agree with that one.
But as I am not one of those users who do not use Akonadi, so it is
certainly not my case to do the convicing work :)
> search turns up hundreds of people asking the same question on Linux
> and technical forums. Akondi has serious performance issues.
Akonadi has dissatisfied users. Not nearly all of the reports you find
on the net are related to performance issues. As not nearly all reports
of your favorite filesystem + "corruption" reveal real stability issues
with filesystems. And it is still good to separate the use cases: How many
reports did you find about the performance impact of an empty and unused
Akonadi that were actually based on *facts*? I *never* saw one. Not even
*one*.
Akonadi has known performance issues, especially for heavy users of KDEPIM
with a lot of mails.
Although there is a major step forward with KDEPIM and Akonadi 18.08,
as Daniel Vrátil fixed one of the known major performance issues in Akonadi
by implementing notification payloads:
https://www.dvratil.cz/2018/04/my-kde-pim-update/
What I still do is to kill akonadi_indexing_agent from time to time – with
KDEPIM and Akonadi 17.12 however still as Sandro is preparing the 18.08
update for Debian. The performance issues it creates are also known to the
developers, including the reason for it. This is one of the next items that
Daniel Vrátil has on his todo list. But akonadi_indexing_agent only creates
those performance issues when there is actually a lot to index. I don´t know
how it will behave with 18.08 yet, I may have to wait till Daniel rewrote
the indexing to put it into the resources themselves for it to improve
substantially.
> If you are a developer I'll be happy to take screen shots Htop and the
> way Akondi crushes a system's memory. […]
htop is not a suitable tool to measure unless is has PSS support meanwhile.
I explained this all in my post about facts about memory usage.
Although I – with a lot of help – fixed a severe performance issue with
local maildir support in Akonadi and provided initial CRM114 spam filtering
wizard configuration developing on Akonadi is not what I do regularly. I
helped to move things forward with performance related issues in Akonadi
some time ago.
The major performance bottle necks are known to KDEPIM developers, but
are challenging to fix as they need good knowledge of how Akonadi work
and are major tasks. We had it all before… countless of times in
kdepim-users. There is a thread I started called something like "review of
database aspect in Akonadi" on kde-pim mailing list that gives a summary
of the major issues. I won´t take the time to repeat it here again.
For people who are really into improving matters with Akonadi and KDEPIM,
read:
KDE PIM Junior Jobs are opened!
https://www.dvratil.cz/2018/08/kde-pim-junior-jobs-are-opened/
Thanks,
--
Martin
More information about the kde
mailing list