| Summary: | After suspend akonadiserver use about 2 cpus | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] Akonadi | Reporter: | Unknown <null> |
| Component: | server | Assignee: | 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 | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| 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
Unknown
2016-06-04 05:52:56 UTC
Created attachment 99356 [details]
htop screenshot
Created attachment 99358 [details]
htop screenshot
Created attachment 99359 [details]
Backtrace of the main akonadiserver process and of all the threads
Created attachment 99360 [details]
Backtrace of the akonadiserver thread probably locking the main process
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... 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 It happened again and after about 20 minutes of huge CPU load, I gave up and did a `akonadictl restart` 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 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. 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 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 |