Bug 307058

Summary:	KMail reacts sluggish but keeps telling my by system notification that it is not broken
Product:	[Applications] kmail2	Reporter:	Marcel Wiesweg <marcel.wiesweg>
Component:	message list	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED UNMAINTAINED
Severity:	normal
Priority:	NOR
Version:	4.9.1
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	KDE system monitor CPU usage

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.