[opensuse-factory] TW 20170825 - 100% system load
![](https://seccdn.libravatar.org/avatar/e85bb1c491d4dd3ebd96110df58f8739.jpg?s=120&d=mm&r=g)
Hi, since I upgraded to latest TW yesterday morning my system is under full load , mainly by akonadiserver, dbus-daemon and mysql. Swap and main memory (8GB each) are fully used, and system is heavily swapping. I hardly can believe that indexing 10GB Mail data and 200 GB files takes more than 10h....on a core i7 with SSD. Tried to log-off and restart the system, but did not help Anyone else observing this? Any ideas for a solution? Thanks Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/e164891e4d850a5cfd6a5765eb3965d0.jpg?s=120&d=mm&r=g)
On 30/08/17 16:34, Axel Braun wrote:
Any ideas for a solution?
- my happy day : get rid of akonadi for ever , and move to xfce [ for me : kmail & kde nuked themselves when akonadi was introduced] ..... cheers -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/482b6c0369f4709de8faa6843cd6b347.jpg?s=120&d=mm&r=g)
On mercredi, 30 août 2017 15.34:41 h CEST Axel Braun wrote:
Hi,
since I upgraded to latest TW yesterday morning my system is under full load , mainly by akonadiserver, dbus-daemon and mysql. Swap and main memory (8GB each) are fully used, and system is heavily swapping.
I hardly can believe that indexing 10GB Mail data and 200 GB files takes more than 10h....on a core i7 with SSD.
Tried to log-off and restart the system, but did not help
Anyone else observing this? Any ideas for a solution?
Thanks Axel
I've got one time trouble, with akonadi already running but not connected to dbus (or the inverse :-) What I've done is killing all akonadi process found with ps axuw | grep akona Then restarted in console with akonadictl --verbose start It was working afterwards, and has started again normally after a shudown and reboot. ps : the only difference is that I'm using postgresql in place of mysql -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/abdee805d4df05af9a496107100c582c.jpg?s=120&d=mm&r=g)
* Axel Braun <axel.braun@gmx.de> [08-30-17 09:37]:
Hi,
since I upgraded to latest TW yesterday morning my system is under full load , mainly by akonadiserver, dbus-daemon and mysql. Swap and main memory (8GB each) are fully used, and system is heavily swapping.
I hardly can believe that indexing 10GB Mail data and 200 GB files takes more than 10h....on a core i7 with SSD.
Tried to log-off and restart the system, but did not help
Anyone else observing this? Any ideas for a solution?
akonadictl restart does: zypper ps -sss show dbus needs to restart, ie: reboot -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/e85bb1c491d4dd3ebd96110df58f8739.jpg?s=120&d=mm&r=g)
Am Mittwoch, 30. August 2017, 16:28:02 CEST schrieb Patrick Shanahan:
* Axel Braun <axel.braun@gmx.de> [08-30-17 09:37]:
Hi,
since I upgraded to latest TW yesterday morning my system is under full load , mainly by akonadiserver, dbus-daemon and mysql. Swap and main memory (8GB each) are fully used, and system is heavily swapping.
I hardly can believe that indexing 10GB Mail data and 200 GB files takes more than 10h....on a core i7 with SSD.
Tried to log-off and restart the system, but did not help
Anyone else observing this? Any ideas for a solution?
akonadictl restart
tried that, as well as restart - same situation as before
does: zypper ps -sss show dbus needs to restart, ie: reboot
this gives no output at all, so no restart required. Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/ec2e857562f9e94f420a54d9a7ce8d79.jpg?s=120&d=mm&r=g)
Op woensdag 30 augustus 2017 15:34:41 CEST schreef Axel Braun:
Hi,
since I upgraded to latest TW yesterday morning my system is under full load , mainly by akonadiserver, dbus-daemon and mysql. Swap and main memory (8GB each) are fully used, and system is heavily swapping.
I hardly can believe that indexing 10GB Mail data and 200 GB files takes more than 10h....on a core i7 with SSD.
Tried to log-off and restart the system, but did not help
Anyone else observing this? Any ideas for a solution?
Thanks Axel
And what about akonadictl fsck akonadictl vacuum -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/6b67eca2c3a817d3c99a508e13b4d1b5.jpg?s=120&d=mm&r=g)
Am Mittwoch, 30. August 2017, 15:34:41 schrieb Axel Braun:
Anyone else observing this? Any ideas for a solution?
One possibility: Akonadi's database structure has changed in 17.08, so the tables will be updated on first start and this can take a while (especially if there are many entries). If you abort that (by logging out or rebooting e.g.), it will have to start again from scratch on next start. So you'd just have to wait it out (or wipe out the database so it will be created fresh which should be faster, but then it would have to redownload and reindex *all* mails instead). Although, that shouldn't cause high CPU load of Akonadi and dbus-daemon I think, Akonadi just sends some SQL queries to mysql and waits until they finish AFAIK. What does "akonadictl status" say? During the database update it should say "not running". Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/e85bb1c491d4dd3ebd96110df58f8739.jpg?s=120&d=mm&r=g)
Am Mittwoch, 30. August 2017, 19:28:02 CEST schrieb Wolfgang Bauer:
One possibility: Akonadi's database structure has changed in 17.08, so the tables will be updated on first start and this can take a while (especially if there are many entries).
That explains things....
If you abort that (by logging out or rebooting e.g.), it will have to start again from scratch on next start. So you'd just have to wait it out (or wipe out the database so it will be created fresh which should be faster, but then it would have to redownload and reindex *all* mails instead).
Bandwidht is not the issue...but 'wiping' probably means to delete ~/.local/ share/akonadi/ ? And all local mails are lost?
Although, that shouldn't cause high CPU load of Akonadi and dbus-daemon I think, Akonadi just sends some SQL queries to mysql and waits until they finish AFAIK.
What does "akonadictl status" say? During the database update it should say "not running".
docb@T520:~> akonadictl status Akonadi Control: running Akonadi Server: running Akonadi Server Search Support: available (Remote Search) Available Agent Types: akonadi_akonotes_resource, akonadi_archivemail_agent, akonadi_birthdays_resource, akonadi_contacts_resource, akonadi_davgroupware_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 and top says: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4322 docb 20 0 2695704 126880 31316 S 98,01 1,576 1:22.55 akonadiserver 4342 docb 20 0 743344 345588 17488 S 86,38 4,293 1:06.43 mysqld 4518 docb 20 0 630280 50292 39668 S 18,94 0,625 0:17.81 akonadi_maildir 4079 docb 20 0 43552 6044 3748 S 17,61 0,075 0:17.13 dbus- daemon -> so this thing is really busy! Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/6b67eca2c3a817d3c99a508e13b4d1b5.jpg?s=120&d=mm&r=g)
Am Mittwoch, 30. August 2017, 20:24:45 schrieb Axel Braun:
Bandwidht is not the issue...but 'wiping' probably means to delete ~/.local/ share/akonadi/ ?
Yes. If you haven't changed the default settings and reconfigured Akonadi to use some other backend or an external server.
And all local mails are lost?
No. Mails are not stored in the database, that is (more or less) just a cache. Mails are stored in standard locations like the maildir or an IMAP server. Although, if there are mails in the cache/database that haven't been synced back to the actual storage, they will be lost. And certain settings refer to ids in the database (destination folders of filters e.g.), that will be lost too.
docb@T520:~> akonadictl status Akonadi Control: running Akonadi Server: running
Then it seems to me that the database upgrade has finished and is not the problem here. No other idea currently, sorry. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/f7cbcea3d34e194aa926d9d62204cc0f.jpg?s=120&d=mm&r=g)
Wolfgang Bauer writes:
One possibility: Akonadi's database structure has changed in 17.08, so the tables will be updated on first start and this can take a while (especially if there are many entries).
Well, it took some time to happen for me, so it was a bit of a surprise when the machine ground to a halt without me doing anything that would trigger that. The issue for me really was that the akonadi process balooned to almost twice the available physical memory (I have 8GB plus the same amount of swap) and was thrashing everything else to swap. I managed to terminate a few large processes to free up enough memory so it didn't run out of swap too (it peaked somwhere around 14.5GiB) and it eventually finished about half an hour later. I have the swap on an SSD, I think it would have taken a lot longer to finish on spinning rust. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 2017-08-30 22:22, Achim Gratz wrote:
Wolfgang Bauer writes:
One possibility: Akonadi's database structure has changed in 17.08, so the tables will be updated on first start and this can take a while (especially if there are many entries).
Well, it took some time to happen for me, so it was a bit of a surprise when the machine ground to a halt without me doing anything that would trigger that. The issue for me really was that the akonadi process balooned to almost twice the available physical memory (I have 8GB plus the same amount of swap) and was thrashing everything else to swap. I managed to terminate a few large processes to free up enough memory so it didn't run out of swap too (it peaked somwhere around 14.5GiB) and it eventually finished about half an hour later. I have the swap on an SSD, I think it would have taken a lot longer to finish on spinning rust.
A process should not demand that huge amount of memory, it should be optimized. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
![](https://seccdn.libravatar.org/avatar/e85bb1c491d4dd3ebd96110df58f8739.jpg?s=120&d=mm&r=g)
Hi, Am Mittwoch, 30. August 2017, 19:28:02 CEST schrieb Wolfgang Bauer:
Am Mittwoch, 30. August 2017, 15:34:41 schrieb Axel Braun:
Anyone else observing this? Any ideas for a solution?
....
So you'd just have to wait it out (or wipe out the database so it will be created fresh which should be faster, but then it would have to redownload and reindex *all* mails instead).
Looks like this saved my life: deleted the ~/.local/share/akonadi folder, After all mails were loaded again, there was a short period of high system load, but now everything is back to normal. As a side effect, explosion/resolution of mailing groups works again. https://bugs.kde.org/show_bug.cgi?id=378011 Crash on writing mail address is gone: https://bugs.kde.org/show_bug.cgi?id=383107 Search index rebuild still broken: https://bugs.kde.org/show_bug.cgi?id=378011 Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Achim Gratz
-
Axel Braun
-
Bruno Friedmann
-
Carlos E. R.
-
ellanios82
-
Knurpht - Gertjan Lettink
-
Patrick Shanahan
-
Wolfgang Bauer