Bug 307058 - KMail reacts sluggish but keeps telling my by system notification that it is not broken
Summary: KMail reacts sluggish but keeps telling my by system notification that it is...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kmail2
Classification: Applications
Component: message list (show other bugs)
Version: 4.9.1
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-19 18:03 UTC by Marcel Wiesweg
Modified: 2017-01-07 22:49 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
KDE system monitor CPU usage (38.70 KB, image/png)
2012-09-22 12:09 UTC, Marcel Wiesweg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel Wiesweg 2012-09-19 18:03:35 UTC
Fresh conversion from kmail1, large local mail dir. Folders have 20k-50k messages. Reading new mail in a folder, going to the next unread message. Reaction is sluggish, 
1) unread mails stay marked as unread in the message list for severeal seconds to minutes, unread counter is correctly decreased in the folder tree view on the left.
2) every now and then showing the mail body fails ( the mail body view shows a "busy message" that the folder's contents are currently being downloaded). Next attempt at showing a mail may succeed
3) kmail/akonadi/mysql eating CPU and memory in the background
4) Often during that time, a system notification pops up: (translated from German translation back to English): "The resource 'KMail folder' is not inoperative. It is now online". Telling me it is not broken via system notification??

I know these are different symptoms but they occur together in one situation so my be caused by the same problem, so a single report by now.

Reproducible: Always

Steps to Reproduce:
1.Take a larger local mail collection
2.Get new mails
3.Open folder for reading, use "+" to navigate to next unread mail
Actual Results:  
as above

Expected Results:  
As fast as KMail1!
Comment 1 Marcel Wiesweg 2012-09-22 12:09:32 UTC
Created attachment 74085 [details]
KDE system monitor CPU usage

A good part of the behavior described above seems to be due to marking a mail as read being extremely CPU intensive in the backends.
I use "+" to read the next unread mail. For a) one mail (first peak) b) four mails (second peak) c) 15 mails (long plateau) being such marked as read the CPU usage is depicted in the attachment.
The involved processes are mysqld (~60%), kontact and the mixelmaildir resource.
As you see, marking 15 mails as read results in about 15 secs of 100% dual core CPU usage.
If I am patient and give it the time it needs, the peculiarities described above do not appear.
Comment 2 Denis Kurz 2016-09-24 18:04:36 UTC
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.
Comment 3 Denis Kurz 2017-01-07 22:49:15 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.