Reducing the memory footprint of Akonadi
October 10, 2011
I have some systems where I don’t use Kontact or anything else that makes use of Akonadi, so my Akonadi database is empty. Still I find the Akonadi server and its numerous agents running when I have just started my session.
The Akonadi server is only started when some application needs it. So who wants to communicate with Akonadi? After some search, I found that the clock applet on the Plasma panel is the culprit. It has a feature to display events from the Akonadi calendar which is enabled by default (and I don’t want to oppose this choice; it’s a very nice integration feature for people using KOrganizer).
So if you want to prevent the Akonadi server from starting on systems where you don’t use Akonadi, or just want to speed up the startup of your KDE session by delaying Akonadi’s startup until it’s actually needed, do the following: Go to the configuration of the clock applet, and disable “Display Events” in the “Calendar” section.
To check whether Akonadi is running, open the “System Activity” monitor with Ctrl+Esc (or by clicking on the second icon from the left in KRunner). Look for a process called “akonadiserver”. (There will also be multiple processes with names like “akonadi_agent_launcher” or “akonadi_whatever_resource”.) You can also manually start and stop Akonadi with the commands “akonadictl start” and “akonadictl stop” (from either the command line or KRunner).
October 10, 2011 at 21:23
[…] I was on my quest of reducing the memory footprint of a freshly launched KDE session, I found that the process which uses most memory just after […]
October 10, 2011 at 22:32
Thanks. Good info there.
I use Kmail, but not the other features of KOrganise and I don’t run a business now, nor do I have a scheduled life.
October 10, 2011 at 23:02
KDE could be very lightweight and fast if it was only desktop, we get a lot of other stuff and new technology but not everyone is using them. Akonadi is example of how resources are wasted for many people, it would be great to have easy way to shut this stuff completely off (it’s possible by text file editing – but akonadi is not going away and it will be harder to disable akonadi in the future as more and more things are going to depend on that – even clock applet)
disabling akonadi server saves about 100MB of ram, for many people it is a lot (and it’s crazy for someone who isn’t using kdePIM at all, 100MB ram for clock applet is insane people 😉
PS personally I’m thunderbird person, no other kdePIM stuff and I’m not the only one, there should be system wide button in system settings “akonadi enable/disable” if disable it should disable all akonadi extensions in whole system (like this clock applet event notification) and shutdown akonadiserver
October 10, 2011 at 23:35
“It has a feature to display events from the Akonadi calendar which is enabled by default (and I don’t want to oppose this choice; it’s a very nice integration feature for people using KOrganizer).”
I do want to oppose it. It should be enabled when KOrganiser is used. Because of all the nice intergration it should be possible right? 😉
October 11, 2011 at 12:04
Why KOrganiser? One of the points of Akonadi is that we’re not limited to specific applications. Any app could talk to Akonadi to be a calendaring app. If the user is using that, and not KOrganiser, the clock’s integration with Akonadi is still a win.
It’s impossible to know which app(s) the user might be using for their calendaring, so having the clock “know” when/if the user is using any Akonadi-based calendaring application is essentially impossible.
October 11, 2011 at 12:34
Maybe we should check if Akonadi is used for storing calendaring then…why is tan essentially impossible?
October 11, 2011 at 15:01
I think what Karellen meant is that since data storage and user interface are decoupled, one user interface (the clock applet) cannot beforehand know which (if any) other user interfaces are used.
What is possible is to check if any resource is capable of providing calendar/event data.
Basically a simple call to Akonadi and filtering the result on capability “resource” and MIME type “text/calendar”
October 11, 2011 at 15:23
There are other solutions: https://bugs.kde.org/show_bug.cgi?id=283745
October 10, 2011 at 23:45
FIled a bug: https://bugs.kde.org/show_bug.cgi?id=283745
October 11, 2011 at 08:15
Hah. I filed a bug about this, too, but in a different direction: https://bugs.kde.org/show_bug.cgi?id=283211
October 11, 2011 at 01:29
Thank you!
October 11, 2011 at 07:07
We ship DisplayEvents=false in the default openSUSE KDE installation’s config files (and in a few other places, there are some KRunners that wake the dragon ;)) so that Akonadi is not started by default.
October 11, 2011 at 08:16
Nice!
October 11, 2011 at 09:03
How c00l, opensuse has modifications that are not shared with upstream 😀
October 12, 2011 at 09:50
This is not about technicalities, it’s about default configuration. It is very common that downstreams (e.g. distros) disagree with the default configuration shipped by upstream (e.g. KDE), for instance because the distribution seeks to appeal to a certain audience.
If you oppose the default configuration shipped by upstream (or downstream, for that matter), you’re welcome to file a bug report and thus spawn a discussion about this.
December 1, 2012 at 22:00
Thanks a lot!
That fixes my … too many files open .. issue