piorunz - 15.04.22, 02:18:38 CEST:
> I noticed that akonadi services are using 100% of 16-core CPU
> resources on my machine. I don't even use Kmail, I use Thunderbird.
I am not happy with Akonadi, but that can do such things even in case an
user does not use it – that is new to me.
> I'm not even sure what akonadi is for. I have following packages
> installed:
>
> $ dpkg -l | grep akonadi | awk {'print $2'}
> akonadi-backend-mysql
[…]
> System is Debian Testing.
>
> How can I get rid of that akonadi, or disable it?
>
> I can't uninstall akonadi-server, because it wants to uninstall with
> it: akonadi-server* kaddressbook* kde-standard* kdepim-runtime*
> kmail* knotes* korganizer* task-kde-desktop*
Which processes of Akonadi are using up the CPU? In case it is just a
certain process like "akonadi_indexing_agent", well what I did with this
one is:
chmod 000 /usr/bin/akonadi_indexing_agent
It works.
Also you can try
akonadictl stop
and see whether it stops the processes that are consuming the CPU. Often
enough it did stop all the processes except MariaDB "mysql" processes
that was still running at full speed for minutes or longer. Especially
in case the indexing agent was involved. Indexing agent is perfectly
capable to drive any database against a wall. It is really that bad.
Do you really not use it? Look at
du -sch ~/.local/share/akonadi/* | sort -rh
If you really do you use it, this should be almost empty beside some
MariaDB journal files.
Note: In case you store contacts in KAdressbook or use a calender with
KOrganizer, you actually *use* Akonadi. Akonadi is not just about
storing mails for KMail.
What I do on systems where I do not use Akonadi – it may even work well
on systems where it is used – is to replace "akonadi-backend-mysql" by
"akonadi-backend-sqlite". That way I get rid of an additional full blown
database process.
I usually also stop Akonadi with
akonadictl stop
And then do
rm -r ~/.local/share/akonadi
rm -r ~/.config/akonadi
Again! Only if you really do not use it, if unsure rather use:
mv ~/.local/share/akonadi ~/.local/share/akonadi-2022-04-nn
mv ~/.config/akonadi ~/.config/akonadi-2022-04-nn
This firstly helps with switching the database, although for that there
are less drastic options like just removing old database and changing
the database driver in ~/.config/akonadi/akonadiserverc or deleting just
that file.
Secondly in addition to getting rid of the external database process it
restores Akonadi to a state where before it was first started – well
except for some other configuration files that are in a different locally,
but I suppose would not matter in this case – so that the condition that
triggered the erratic behavior of Akonadi likely is done way with.
And now: Wow!
I still believe the end user should not have to do with any of this.
Akonadi is something that drags down the overall good Plasma / KDE
experience unfortunately since more than a decade. I defended it earlier
on. Meanwhile I think it is better to completely replace it.
For example by something like Evolution from GNOME uses. I use Evolution
at work and it has none of the issues that Akonadi brings into those
very nice KDEPIM applications like KMail.
Best,
--
Martin
