After a day of akonadi running (mail resources), the server consumes almost all memory ..., making it unusable. Unfortunately, I cannot say anything more detailed, except it may be related with (imap) mail resources, since it seems that the memory does not grow hen mail is off-line (I will try to confirm it). Is there something I should try to help you? There is a [top] short after the start of akonadi server and setting mails resources to be on-line top - 20:51:29 up 2 days, 4:31, 2 users, load average: 1.31, 1.15, 1.04 Tasks: 22 total, 0 running, 22 sleeping, 0 stopped, 0 zombie %Cpu(s): 4.1 us, 0.8 sy, 0.0 ni, 95.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 32083.1 total, 26416.1 free, 3061.1 used, 2605.9 buff/cache MiB Swap: 32768.0 total, 32703.1 free, 64.9 used. 27706.4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10838 dtihelka 20 0 3451504 179168 30804 S 6.7 0.5 65:44.97 /bin/akonadiserver 10898 dtihelka 20 0 1207552 85632 68896 S 0.0 0.3 6:29.99 /usr/bin/akonadi_mailfilter_agent --identifier akonadi_mailfilter_agent 10885 dtihelka 20 0 1199128 83552 66944 S 0.0 0.3 6:23.71 /usr/bin/akonadi_archivemail_agent --identifier akonadi_archivemail_agent 10887 dtihelka 20 0 1128872 81676 65460 S 0.0 0.2 0:02.85 /usr/bin/akonadi_googlecalendar_resource --identifier akonadi_googlecalendar_resource_0 10911 dtihelka 20 0 1191836 79944 63688 S 0.0 0.2 4:54.27 /usr/bin/akonadi_sendlater_agent --identifier akonadi_sendlater_agent 10888 dtihelka 20 0 1061980 77340 61408 S 0.0 0.2 0:02.86 /usr/bin/akonadi_googlecontacts_resource --identifier akonadi_googlecontacts_resource_0 10889 dtihelka 20 0 1087020 74704 59188 S 0.0 0.2 0:03.04 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_1 10890 dtihelka 20 0 1087024 73380 58072 S 0.0 0.2 0:02.81 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_2 10891 dtihelka 39 19 666488 52460 40992 S 0.0 0.2 6:17.63 /usr/bin/akonadi_indexing_agent --identifier akonadi_indexing_agent 10904 dtihelka 20 0 847528 47116 41660 S 0.0 0.1 0:02.73 /usr/bin/akonadi_notes_agent --identifier akonadi_notes_agent 10895 dtihelka 20 0 645644 46764 38504 S 0.0 0.1 17:22.84 /usr/bin/akonadi_maildir_resource --identifier akonadi_maildir_resource_0 10903 dtihelka 20 0 669516 45724 40496 S 0.0 0.1 4:54.91 /usr/bin/akonadi_newmailnotifier_agent --identifier akonadi_newmailnotifier_agent 10884 dtihelka 20 0 635812 43664 38712 S 0.0 0.1 0:00.99 /usr/bin/akonadi_akonotes_resource --identifier akonadi_akonotes_resource_2 10897 dtihelka 20 0 718660 43348 38380 S 0.0 0.1 2:02.30 /usr/bin/akonadi_maildispatcher_agent --identifier akonadi_maildispatcher_agent 10886 dtihelka 20 0 725320 43316 38316 S 0.0 0.1 5:03.77 /usr/bin/akonadi_followupreminder_agent --identifier akonadi_followupreminder_agent 10905 dtihelka 20 0 714392 43296 38404 S 0.0 0.1 0:02.68 /usr/bin/akonadi_pop3_resource --identifier akonadi_pop3_resource_0 10882 dtihelka 20 0 635836 42972 38016 S 0.0 0.1 0:00.97 /usr/bin/akonadi_akonotes_resource --identifier akonadi_akonotes_resource_0 10883 dtihelka 20 0 633444 42628 37776 S 0.0 0.1 0:00.98 /usr/bin/akonadi_akonotes_resource --identifier akonadi_akonotes_resource_1 10901 dtihelka 20 0 622076 40784 36088 S 0.0 0.1 0:00.98 /usr/bin/akonadi_migration_agent --identifier akonadi_migration_agent 10799 dtihelka 20 0 536372 38432 33576 S 0.0 0.1 4:48.58 /bin/akonadi_control 8 root -2 0 0 0 0 I 0.0 0.0 0:51.09 [rcu_preempt] 2 root 20 0 0 0 0 S 0.0 0.0 0:00.04 [kthreadd] and the [top] few hours later: top - 07:51:30 up 3 days, 15:31, 2 users, load average: 0.16, 0.27, 0.34 Tasks: 22 total, 0 running, 22 sleeping, 0 stopped, 0 zombie %Cpu(s): 2.4 us, 0.0 sy, 0.0 ni, 97.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 32083.1 total, 283.4 free, 30582.4 used, 1217.2 buff/cache MiB Swap: 32768.0 total, 24149.8 free, 8618.2 used. 118.7 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10838 dtihelka 20 0 34.8g 26.7g 2280 S 0.0 85.4 214:25.36 /bin/akonadiserver 10889 dtihelka 20 0 1372680 12576 5484 S 0.0 0.0 8:10.85 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_1 10890 dtihelka 20 0 1349560 11976 6296 S 0.0 0.0 0:24.00 /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_2 10895 dtihelka 20 0 645448 9660 4340 S 0.0 0.0 48:30.77 /usr/bin/akonadi_maildir_resource --identifier akonadi_maildir_resource_0 10888 dtihelka 20 0 1063592 6664 3928 S 0.0 0.0 0:13.87 /usr/bin/akonadi_googlecontacts_resource --identifier akonadi_googlecontacts_resource_0 10898 dtihelka 20 0 1208008 5872 4304 S 0.0 0.0 17:55.51 /usr/bin/akonadi_mailfilter_agent --identifier akonadi_mailfilter_agent 10911 dtihelka 20 0 1191836 5696 4520 S 0.0 0.0 13:34.16 /usr/bin/akonadi_sendlater_agent --identifier akonadi_sendlater_agent 10891 dtihelka 39 19 965336 5580 3592 S 0.0 0.0 17:21.37 /usr/bin/akonadi_indexing_agent --identifier akonadi_indexing_agent 10885 dtihelka 20 0 1199260 5004 3836 S 0.0 0.0 17:37.54 /usr/bin/akonadi_archivemail_agent --identifier akonadi_archivemail_agent 10887 dtihelka 20 0 1128872 4768 3960 S 0.0 0.0 0:12.30 /usr/bin/akonadi_googlecalendar_resource --identifier akonadi_googlecalendar_resource_0 10905 dtihelka 20 0 720020 4640 3160 S 0.0 0.0 0:12.21 /usr/bin/akonadi_pop3_resource --identifier akonadi_pop3_resource_0 10897 dtihelka 20 0 911472 4528 2980 S 0.0 0.0 5:39.47 /usr/bin/akonadi_maildispatcher_agent --identifier akonadi_maildispatcher_agent 10903 dtihelka 20 0 745772 3936 2912 S 0.0 0.0 13:32.75 /usr/bin/akonadi_newmailnotifier_agent --identifier akonadi_newmailnotifier_agent 10904 dtihelka 20 0 847528 3668 2948 S 0.0 0.0 0:12.12 /usr/bin/akonadi_notes_agent --identifier akonadi_notes_agent 10886 dtihelka 20 0 725320 3264 2376 S 0.0 0.0 13:59.23 /usr/bin/akonadi_followupreminder_agent --identifier akonadi_followupreminder_agent 10901 dtihelka 20 0 622076 2876 2272 S 0.0 0.0 0:03.71 /usr/bin/akonadi_migration_agent --identifier akonadi_migration_agent 10883 dtihelka 20 0 633444 2848 2360 S 0.0 0.0 0:03.74 /usr/bin/akonadi_akonotes_resource --identifier akonadi_akonotes_resource_1 10884 dtihelka 20 0 635812 2748 2336 S 0.0 0.0 0:03.73 /usr/bin/akonadi_akonotes_resource --identifier akonadi_akonotes_resource_2 10799 dtihelka 20 0 536372 2732 1672 S 0.0 0.0 13:22.32 /bin/akonadi_control 10882 dtihelka 20 0 635836 2264 1916 S 0.0 0.0 0:03.73 /usr/bin/akonadi_akonotes_resource --identifier akonadi_akonotes_resource_0 8 root -2 0 0 0 0 I 0.0 0.0 1:29.03 [rcu_preempt] 2 root 20 0 0 0 0 S 0.0 0.0 0:00.05 [kthreadd] >> akonadictl status Akonadi Control: running Akonadi Server: running Akonadi Server Search Support: available (Remote Search, Akonadi Search Plugin) Available Agent Types: akonadi_akonotes_resource, akonadi_archivemail_agent, akonadi_birthdays_resource, akonadi_contacts_resource, akonadi_davgroupware_resource, akonadi_ews_resource, akonadi_ewsmta_resource, akonadi_facebook_resource, akonadi_followupreminder_agent, akonadi_googlecalendar_resource, akonadi_googlecontacts_resource, akonadi_ical_resource, akonadi_icaldir_resource, akonadi_imap_resource, akonadi_indexing_agent, akonadi_invitations_agent, akonadi_kalarm_dir_resource, akonadi_kalarm_resource, akonadi_knut_resource, akonadi_kolab_resource, akonadi_maildir_resource, akonadi_maildispatcher_agent, akonadi_mailfilter_agent, akonadi_mbox_resource, akonadi_migration_agent, akonadi_mixedmaildir_resource, akonadi_newmailnotifier_agent, akonadi_notes_agent, akonadi_notes_resource, akonadi_openxchange_resource, akonadi_pop3_resource, akonadi_sendlater_agent, akonadi_tomboynotes_resource, akonadi_vcard_resource, akonadi_vcarddir_resource
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
(In reply to sombriks from comment #18) > Hi, i can confirm that bug still occurs ... > using openSUSE Tumbleweed kernel 6.5.6-1-default Also occurs with: openSUSE Tumbleweed 20240509 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.8-1-default (64-bit) Graphics Platform: Wayland