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).

16 Responses to “Reducing the memory footprint of Akonadi”


  1. […] 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 […]

  2. e8hffff Says:

    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.

  3. fasd Says:

    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

  4. BartOtten Says:

    “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? 😉

    • Karellen Says:

      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.

      • BartOtten Says:

        Maybe we should check if Akonadi is used for storing calendaring then…why is tan essentially impossible?


        • 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”

        • BartOtten Says:

          There are other solutions: https://bugs.kde.org/show_bug.cgi?id=283745

  5. John Doe Says:

    Thank you!


  6. 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.

  7. Manolin Says:

    How c00l, opensuse has modifications that are not shared with upstream 😀

    • Stefan Majewsky Says:

      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.

  8. Peter Says:

    Thanks a lot!

    That fixes my … too many files open .. issue


Leave a comment