Bug 363928

Summary: After suspend akonadiserver use about 2 cpus
Product: Akonadi Reporter: franz.bergesund
Component: serverAssignee: kdepim bugs <kdepim-bugs>
Status: REPORTED ---    
Severity: normal CC: a.samirh78, dvratil, kde-bugs, kleagg, olaf.the.lost.viking
Priority: NOR    
Version: 5.2.0   
Target Milestone: ---   
Platform: openSUSE RPMs   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: htop screenshot
htop screenshot
Backtrace of the main akonadiserver process and of all the threads
Backtrace of the akonadiserver thread probably locking the main process

Description franz.bergesund 2016-06-04 05:52:56 UTC
Since a month or two, from time to time upon resuming from sleep, akonadiserver occupies about 2 CPUs, making the computer verey slow at reacting.
When it happens, htop shows the main akonadisever process and one of its threads in the top of the list. Killing the thread or issuing akonadictl restart solves the problem and the mail works fine afterwards.

I did also report this to the opensuse-kde mailing list (https://lists.opensuse.org/opensuse-kde/2016-04/msg00092.html)

Since a while I have only my work email connected to kmail via IMAP. I used to have google calendar and address book, but I removed both of them a month or so ago.

Reproducible: Sometimes

Steps to Reproduce:
1. put the computer to sleep
2. resume from sleep
3.

Actual Results:  
sometimes akonadiserver get stuck with very high CPU usage


This happens on a Dell Latitude E6430s with
openSUSE Tumbleweed (20160531)
akonadi-server: 16.04.1
kdepim: 16.04.1
Comment 1 franz.bergesund 2016-06-04 05:53:46 UTC
Created attachment 99356 [details]
htop screenshot
Comment 2 franz.bergesund 2016-06-04 05:55:35 UTC
Created attachment 99358 [details]
htop screenshot
Comment 3 franz.bergesund 2016-06-04 05:57:02 UTC
Created attachment 99359 [details]
Backtrace of the main akonadiserver process and of all the threads
Comment 4 franz.bergesund 2016-06-04 05:57:36 UTC
Created attachment 99360 [details]
Backtrace of the akonadiserver thread probably locking the main process
Comment 5 Daniel Vrátil 2016-07-20 21:17:48 UTC
I see only one active thread in middle of an SQL query execution, could easily be a full sync after reconnecting to network after resume from suspend.

How long does it get stuck in such state? It is possible that during the suspend large portions of the database pages get swapped out of memory and then the query takes a very long time as the database needs to load everything from the disk again...
Comment 6 franz.bergesund 2016-07-21 13:25:22 UTC
I just resumed from suspension and akonadiserver was up and running at full speed. After a few minutes I got the notification that my emails had been updated.
It took about 10 minutes for akonadiserver to get back to normal.

/, /home and /swap are on a SSD that the System load viewer don't show any big problem with swap.

This time was reasonable. But sometimes it happens together with bug 363909 [https://bugs.kde.org/show_bug.cgi?id=363909], making the computer basically useless until I restart either akonadi or plasmashell
Comment 7 franz.bergesund 2016-07-23 07:00:40 UTC
It happened again and after about 20 minutes of huge CPU load, I gave up and did a `akonadictl restart`
Comment 8 franz.bergesund 2016-10-24 19:06:01 UTC
I keep getting this issue and frankly is very annoying that every second or third suspend I have to wait 10 or 20 minutes or restart akonadi.

Right now I'm connected to the network.

I'm on:
* OpenSUSE Tumbleweed: 20161023
* plasma 5.8.2
* KF 5.26.0
* kdepim: 16.08.2-1.1 from repository: repo-oss
Comment 9 Gaël de Chalendar (aka Kleag) 2020-05-12 12:37:45 UTC
I have the same problem since a very long time (I should have reported it earlier). I'm on an up to date KDE Neon:

Operating System: KDE neon 5.18
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.70.0
Qt Version: 5.14.2
Kernel Version: 5.3.0-51-generic
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-8650U CPU @ 1.90GHz
Memory: 31,2 Gio

My PC stays usable because I have 8 cores. But it's getting hot and it draws the battery very quickly when not plugged in.

My .xsession-errors shows a continuous stream of
org.kde.pim.akonadi_indexer_agent: Xapian error in indexer 0x55f584d189d0 : Db block overwritten - are there multiple writers?
org.kde.pim.akonadiserver: ItemRetrievalJob for request 0x7f2fec02ef70 finished
org.kde.pim.akonadi_indexer_agent: Xapian error in indexer 0x55f584d189d0 : Db block overwritten - are there multiple writers?
org.kde.pim.akonadiserver: ItemRetrievalJob for request 0x7f2fec043d90 finished
org.kde.pim.akonadi_indexer_agent: Xapian error in indexer 0x55f584d189d0 : Db block overwritten - are there multiple writers?

Around one by second.

I have one akonadi_ews_resource to an exchange server, two calendars and a large maildir local archive.
Comment 10 Ahmad Samir 2020-08-18 17:47:47 UTC
The Xapian errors from the log, in the previous comment, will probably be fixed by https://invent.kde.org/pim/akonadi-search/-/merge_requests/2
Comment 11 Ahmad Samir 2020-08-19 16:08:26 UTC
Git commit ff6cdf57350228004ad431b7b0d98fa8d3f7d120 by Ahmad Samir.
Committed on 18/08/2020 at 17:41.
Pushed by dvratil into branch 'master'.

Fix crash by handling exceptions thrown by GlassTable::set_overwritten

Xapian::Enquire::get_mset ultimately calls GlassTable::block_to_cursor,
which could throw Xapian::DatabaseModifiedError if the database has been
modified/deviated too much since it was opened for searching; handle that
case by trying to call reopen on the database (as per the upstream error
message[1]), then query it again, if that fails just return.

Also handle one other exception, Xapian::DatabaseCorruptError; this has
been reported in [2].

Use QByteArray::toStdString when calling the Xapian::Database ctor.

[1] https://xapian.org/docs/sourcedoc/html/glass__table_8cc_source.html#l00288
[2] https://bugs.kde.org/show_bug.cgi?id=363928#c9
Related: bug 401865

M  +24   -5    lib/indexeditems.cpp

https://invent.kde.org/pim/akonadi-search/commit/ff6cdf57350228004ad431b7b0d98fa8d3f7d120