| Summary: | Regression in 5.6.0 / 17.08 compared to 17.04.3: MySQL load always 100%, constant queries, extremely sluggisch behaviour | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] Akonadi | Reporter: | Gunter Ohrner <kdebugs> |
| Component: | IMAP resource | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | danielroschka, egdfree, kdepim-bugs, matish, ogoffart |
| Priority: | NOR | ||
| Version: | 5.6.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Screenshot Akonadiconsole Query Sequence Debugger
akonadiconsole showing the queries to the db |
||
|
Description
Gunter Ohrner
2017-09-04 17:07:41 UTC
Update: Akonadi is really keeping mysqld at 100%, all the time, all day, independently of if I quit kmail or not. I need to stop akonadiserver (akonadictl stop) to make it stop after a while. So maybe this needs to be reassigned to akonadi? It renders all akonadi using software more or less unusable, including kaddressbook... Created attachment 107732 [details]
Screenshot Akonadiconsole Query Sequence Debugger
The query debugger query sequence view "nicely" illustrates the problem:
The second query is very slow with 650 ms execution time per call, and uses most of the processing time.
The sum shown as "TOTAL" basically resembles wall clock time, as Akonadi loads the CPU 100% (actually mysqld).
This never seems to finish, at least it ran for lots of hours several times, before I finally terminated it using "akonadictl stop".
Not quite sure if really IMAP ressource is the culprit, but I think so. How can I find out who or what is triggering all those (slow) queries? For whatever reason, the query storm stopped on my system. Now kMail is still as slow as ever, but more or less usable again. Meanwhile I also upgraded to 5.6.1 - no idea if it's related to this improvement or if both are independent events. Is anyone else seeing this problem? Otherwise I'll probably close the bug. Or does one of the developers fear / see a problem here and want to keep this issue open to have a reminder for having a look at it? I get mysqld, kontact, akonadiserver, korgac, and akonadi_ical_resource that run like crazy and whose memory footprint grows indefinitely. kmail seems to be fine, the madness starts when I run korganizer, or open the calendar within kontact. By looking at akonadiconsole the db is queried pretty much continuously, I'm attaching a screen shot after a few seconds. I am running 17.04.2, Kde Frameworks 5.32, qt 5.6.2, on OpenSUSE 42.3. Let me know if there's anything I can do to get more info. Thanks. Created attachment 108214 [details]
akonadiconsole showing the queries to the db
ok, I found out that my problem is with google calendars. I had a google calendar displayed in korganizer and korgc was using 3.5 GB of memory, and running queries like there was no tomorrow. I removed the calendar and it seems to be ok. So maybe these are two different issues... not sure. apologies for the many comments... I made a mistake, it was not a google calendar but a remote ics file, imported from office365. I got the exactly the same problem after updating to KDE PIM 17.08 and haven't been able to solve it yet. I might have figured out what caused the issue. The search folder in KMail showed 100000 results and when I opened the search window it showed the search folder itself as destination for the search. I then did a search in a different folder and the problem immediately went away. So my guess is that it's somehow an odd default which results in a recursive search, as the search searches in the search results. I haven't been able to reproduce it once it was gone, but luckily the problem is gone for me now. Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |