Further observation confirmed that the memory usage is still growing even when mail accounts are off-line (set through "work off-line" in kontact menu). Although the growing is very slow ...

The issue started sometime in June, so must be related to releases 18.04.1 or 18.04.2 in Arch. I can confirm that reverting akonadi* packages to 18.04.0 makes the memory creep go away.

$ sudo pacman -U /var/cache/pacman/pkg/akonadi*-18.04.0-1-x86_64.pkg.tar.gz

akonadi (18.04.2-3 -> 18.04.0-1)
akonadi-contacts (18.04.2-1 -> 18.04.0-1)
akonadi-mime (18.04.2-1 -> 18.04.0-1)
akonadi-calendar (18.04.2-1 -> 18.04.0-1)
akonadi-search (18.04.2-1 -> 18.04.0-1)
akonadi-calendar-tools (18.04.2-1 -> 18.04.0-1)
akonadiconsole (18.04.2-1 -> 18.04.0-1)
akonadi-import-wizard (18.04.2-1 -> 18.04.0-1)
akonadi-notes (18.04.2-1 -> 18.04.0-1)

I hope this helps narrow down the cause.

After a day of switching versions and just observing the memory usage, I'm happy to report that the problem occurs when upgrading from akonadi* 18.04.0 to 18.04.1. With 18.04.0 packages, akonadiserver uses just under 10 MB of memory and holds stable. Switching to 18.04.1, akonadiserver starts using increasing amounts of memory without an upper bound. Within a few hours, it uses a few gigabytes of memory.

1. Whatever is causing this is in the 18.04.0 -> 18.04.1 update.
2. Downgrading akonadi* packages to 18.04.0 as per my last email is a viable workaround (with no noticeable loss of functionality).

I have a final update and possible fix for this. The latest release (18.04) continued to have this memory ballooning issue. I ran akonadictl fsck, which reported a mysql error when checking one of the folders in one of my mail accounts. It was unable to find a field in some query. I'm sorry I didn't note down this query and the error.

My kmail setup is probably more than three years old at this point and in the meantime, akonadi has had several updates. It's possible that the schema for the database changed in that time and wasn't cleanly updated from one version to the next. So, I suggest using the fsck operation as an indicator for checking if this would work. Onwards to the fix.

I wanted to rebuild the internal database. Remove ~/.local/share/akonadi and all its contents. I did this from a virtual console rather than from within a plasma session, but I suppose you could do this with akonadi stopped, too. After deleting this directory, login/open kmail. All the accounts and their folders should go blank. I had to authenticate my main mail account again (if you see a dialog that doesn't close, and you use gmail, it might be the authentication page from google. Drag and make the dialog window bigger to see it.). Now, all the mail gets re-downloaded and akonadi has been zippy as all hell. The behavior is stable across multiple reboots and I'm satisfied the issue is fixed.

Note that if you have any changes that haven't synced with the imap server, you may lose them. Sync before doing this.

If OP (Dan) can confirm this works, this bug can be closed. If any dev wants to reproduce this, maybe start with an old version of akonadi and jump directly to a new release. fsck should fail and you should have a ballooning memory usage with each mail check.

Thanks!

I also ran into the same problem. I believe that the problem in this case may be that your akonadi mysql database is older than what the latest mariadb or mysql server versions you have installed on the system will allow. Regrettably, it is not evident how to log into the maridb instance that akonadi is using to that the database can be upgraded. In any case, the workaround is as you have described. delete the entire akonadi mysql database.

I seem to have had the same issue.
I can confirm that ~/.local/share/akonadi solved it for me.
I am running Kubuntu 18.04 and my installation is older, meaning akonadi was set up 1..2 years ago.

*** Bug 401056 has been marked as a duplicate of this bug. ***

I also see this issue on two systems:

* Fedora 29: kf5-akonadi-server, version 18.12.2, release 1.fc29
  - Was running Arch from 2016 until 2019-02-16, kept $HOME after the switch
* Gentoo: kde-apps/akonadi version 18.12.3
  - Was always (since 2003) running Gentoo, keeping the same $HOME

It became unbearable only in the last 1-2 months -- I did not notice it earlier.  On neither system I can easily downgrade to 18.04.0.

(In reply to Dennis Schridde from comment #8)
> I also see this issue on two systems:
> 
> * Fedora 29: kf5-akonadi-server, version 18.12.2, release 1.fc29
>   - Was running Arch from 2016 until 2019-02-16, kept $HOME after the switch
> * Gentoo: kde-apps/akonadi version 18.12.3
>   - Was always (since 2003) running Gentoo, keeping the same $HOME
> 
> It became unbearable only in the last 1-2 months -- I did not notice it
> earlier.  On neither system I can easily downgrade to 18.04.0.

P.S. `akonadictl fsck` reports no MySQL errors.

I just noticed similar problem on openSUSE Tumbleweed snapshot 20190315 with KDE Applications 18.12.3. The System Monitor reports about 5GB memory taken by akonadiserver. After restarting akonadi, the memory taken starts from around 40MB. This issue didn't occur before.

(In reply to CnZhx from comment #10)
> I just noticed similar problem on openSUSE Tumbleweed snapshot 20190315 with
> KDE Applications 18.12.3. The System Monitor reports about 5GB memory taken
> by akonadiserver. After restarting akonadi, the memory taken starts from
> around 40MB. This issue didn't occur before.

Ok, after rebuild the data storage, the memory taken by akonadiserver backs to normal.

cnzhx@ostp:~> akonadictl stop
cnzhx@ostp:~> mv ~/.local/share/akonadi/ ~/.local/share/akonadi.backup/
cnzhx@ostp:~> akonadictl start

Then let Kontact re-retrieve the mails.

I also notice regularly (maybe related?) that `akonadictl fsck` finds a lot of "Cleaning up missing external file: ..." and "Found unreferenced external file: ...".  ~/.local/share/akonadi/file_lost+found/ contains 3.5 million files.  Akonadi regularly re-downloads entire folders via IMAP, after printing on the console that it detected a mismatch in the number of emails in that folder between itself and the IMAP server.

(In reply to Dennis Schridde from comment #9)
> (In reply to Dennis Schridde from comment #8)
> > I also see this issue on two systems:
> > 
> > * Fedora 29: kf5-akonadi-server, version 18.12.2, release 1.fc29
> >   - Was running Arch from 2016 until 2019-02-16, kept $HOME after the switch
> > * Gentoo: kde-apps/akonadi version 18.12.3
> >   - Was always (since 2003) running Gentoo, keeping the same $HOME
> > 
> > It became unbearable only in the last 1-2 months -- I did not notice it
> > earlier.  On neither system I can easily downgrade to 18.04.0.
> 
> P.S. `akonadictl fsck` reports no MySQL errors.

I found this warning in mysqld.err:
[Warning] InnoDB: Table mysql/innodb_table_stats has length mismatch in the column name table_name.  Please run mysql_upgrade

(In reply to Dennis Schridde from comment #13)
> (In reply to Dennis Schridde from comment #9)
> > P.S. `akonadictl fsck` reports no MySQL errors.
> 
> I found this warning in mysqld.err:
> [Warning] InnoDB: Table mysql/innodb_table_stats has length mismatch in the
> column name table_name.  Please run mysql_upgrade

Fix:
mysql_upgrade --socket=$TMPDIR/akonadi-$USER.*/mysql.socket

Created attachment 129000 [details]
pmap file for akonadiserver

I have a suimilar issue, before I resolved clearing the .local/akonadi data but after a day of indexing I have all the memory (and swap file) full off "akonadiserver":
akonadiserver 5.10.3 on openSUSE_15.1 akonadi-server-18.12.3-lp151.3.4.1.x86_64
mariadb-10.2.31-lp151.2.12.1.x86_64

(my system have 16GB of internal memory)

The user experience note is that, starting from a clean akonadi data directory I have:

I started with exit "kontact", akonadictl stop, removing the  ~/.local/share/akonadi
killed everything in processtable that have "akonadi or imap" in it:

and this is the state after a day:
20Gbytes     ~/.local/share/akonadi

diego    32758  0.9  0.1 1637424 20172 ?       Sl   giu01  12:42 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_6
diego    32759  0.2  0.0 1663212 12016 ?       Sl   giu01   3:49 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_7
diego@pc-diego:~: ps axuww | grep akonadi
diego      302  0.0  0.0 729544  1448 ?        Sl   giu01   1:19 /usr/bin/akonadi_maildispatcher_agent --identifier akonadi_maildispatcher_agent
diego      303  0.0  0.0 1492968 13436 ?       Sl   giu01   0:57 /usr/bin/akonadi_mailfilter_agent --identifier akonadi_mailfilter_agent
diego      309  0.0  0.0 619480  1056 ?        Sl   giu01   0:55 /usr/bin/akonadi_migration_agent --identifier akonadi_migration_agent
diego      310  0.0  0.0 670200  1572 ?        Sl   giu01   0:58 /usr/bin/akonadi_newmailnotifier_agent --identifier akonadi_newmailnotifier_agent
diego      313  0.0  0.0 865748  3348 ?        Sl   giu01   1:20 /usr/bin/akonadi_notes_agent --identifier akonadi_notes_agent
diego      315  0.0  0.0 1387732 3900 ?        Sl   giu01   1:17 /usr/bin/akonadi_sendlater_agent --identifier akonadi_sendlater_agent
diego      316  0.0  0.0 1337828 3336 ?        Sl   giu01   0:56 /usr/bin/akonadi_unifiedmailbox_agent --identifier akonadi_unifiedmailbox_agent
diego     6929  0.0  0.0   8696   916 pts/14   S+   15:44   0:00 grep --color=auto akonadi
diego    15866  7.2  1.1 4737432 195268 ?      Sl   giu01 131:46 /usr/sbin/mysqld --defaults-file=~/diego/.local/share/akonadi/mysql.conf --datadir=~/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-diego.VKwzOA/mysql.socket --pid-file=/tmp/akonadi-diego.VKwzOA/mysql.pid
diego    32709  0.1  0.0 538692  1516 ?        Sl   giu01   1:45 /usr/bin/akonadi_control
diego    32713  1.0 39.0 19785920 6378120 ?    Sl   giu01  14:14 akonadiserver
diego    32732  0.0  0.0 627564  1112 ?        Sl   giu01   0:54 /usr/bin/akonadi_akonotes_resource --identifier akonadi_akonotes_resource_0
diego    32733  0.0  0.0 625056   996 ?        Sl   giu01   0:54 /usr/bin/akonadi_akonotes_resource --identifier akonadi_akonotes_resource_1
diego    32734  0.0  0.0 1427624 8728 ?        Sl   giu01   0:58 /usr/bin/akonadi_archivemail_agent --identifier akonadi_archivemail_agent
diego    32735  0.0  0.0 629012   960 ?        Sl   giu01   0:54 /usr/bin/akonadi_birthdays_resource --identifier akonadi_birthdays_resource
diego    32738  0.0  0.0 619412   984 ?        Sl   giu01   0:54 /usr/bin/akonadi_contacts_resource --identifier akonadi_contacts_resource_0
diego    32741  0.0  0.0 713184  1592 ?        Sl   giu01   1:14 /usr/bin/akonadi_followupreminder_agent --identifier akonadi_followupreminder_agent
diego    32742  0.0  0.0 1319236 5436 ?        Sl   giu01   1:19 /usr/bin/akonadi_googlecalendar_resource --identifier akonadi_googlecalendar_resource_1
diego    32751  0.0  0.0 635156   976 ?        Sl   giu01   0:55 /usr/bin/akonadi_ical_resource --identifier akonadi_ical_resource_0
diego    32758  0.9  0.1 1637424 20172 ?       Sl   giu01  12:42 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_6
diego    32759  0.2  0.0 1663212 12016 ?       Sl   giu01   3:49 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_7
diego    32760  0.0  0.0 730636  6224 ?        SNl  giu01   1:09 /usr/bin/akonadi_indexing_agent --identifier akonadi_indexing_agent
diego    32765  1.9  0.5 1298064 91292 ?       Sl   giu01  26:39 /usr/bin/akonadi_kolab_resource --identifier akonadi_kolab_resource_0
diego    32766  0.0  0.0 628272  1364 ?        Sl   giu01   0:56 /usr/bin/akonadi_maildir_resource --identifier akonadi_maildir_resource_2

Finally I think I've found my hickup:
There was a package installed
akonadi-search-18.12.3-lp151.1.3.x86_64

/etc/xdg/akonadi-search.categories
/etc/xdg/akonadi-search.renamecategories
/usr/bin/akonadi_indexing_agent
/usr/lib64/qt5/plugins/akonadi
/usr/lib64/qt5/plugins/akonadi/akonadi_search_plugin.so
/usr/lib64/qt5/plugins/akonadi/calendarsearchstore.so
/usr/lib64/qt5/plugins/akonadi/contactsearchstore.so
/usr/lib64/qt5/plugins/akonadi/emailsearchstore.so
/usr/lib64/qt5/plugins/akonadi/notesearchstore.so
/usr/lib64/qt5/plugins/kcm_krunner_pimcontacts.so
/usr/lib64/qt5/plugins/krunner_pimcontacts.so
/usr/share/akonadi
/usr/share/akonadi/agents
/usr/share/akonadi/agents/akonadiindexingagent.desktop
/usr/share/kservices5/plasma-krunner-pimcontacts.desktop
/usr/share/kservices5/plasma-krunner-pimcontacts_config.desktop
/usr/share/licenses/akonadi-search
/usr/share/licenses/akonadi-search/COPYING
/usr/share/licenses/akonadi-search/COPYING.LIB

Installed which akonadi consumes all the memory

I just removed the package

Hi, i can confirm that bug still occurs, is there any other solution rather remove akonadi components?

using openSUSE Tumbleweed kernel 6.5.6-1-default