Bug 235607 - kmail or kontact using a lot of CPU and disk when starting reading mail folders
Summary: kmail or kontact using a lot of CPU and disk when starting reading mail folders
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kmail2
Classification: Applications
Component: general (show other bugs)
Version: 4.9.0
Platform: openSUSE Unspecified
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 232047 251240 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-04-28 10:46 UTC by Roman Fietze
Modified: 2017-01-07 22:28 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Fietze 2010-04-28 10:46:16 UTC
Version:            (using KDE 4.4.2)
Installed from:    openSUSE RPMs

When I exit kontact properly and start it the next day, kontact uses a lot of CPU and disk resources. The system, esp. kontact/kmail is sluggish for 2-3 minutes when this happens. It seems kmail is reading in all known folders.

When I exit kontact properly and start it again right away I cannot see that behaviour. See below about expiration and size of the trash folder.

An "strace -p" with the PID of kontact gives me the following output:

stat("/home/fietze/Mail/trash/cur/1271315469.4440.rV06y:2,S", {st_mode=S_IFREG|0644, st_size=5198, ...}) = 0
stat("/home/fietze/Mail/trash/cur/1271315469.4440.rV06y:2,S", {st_mode=S_IFREG|0644, st_size=5198, ...}) = 0
open("/home/fietze/Mail/trash/cur/1271315469.4440.rV06y:2,S", O_RDONLY) = 19
fstat(19, {st_mode=S_IFREG|0644, st_size=5198, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f784a1b3000
read(19, "Return-Path: <mkossmann_ml1@gmx."..., 4096) = 4096
read(19, "ze by SMTP Server on muc/Telemot"..., 4096) = 1102
close(19)                               = 0
munmap(0x7f784a1b3000, 4096)            = 0
stat("/home/fietze/Mail/trash/cur/1271315469.4440.NyNjj:2,S", {st_mode=S_IFREG|0644, st_size=7150, ...}) = 0
stat("/home/fietze/Mail/trash/cur/1271315469.4440.NyNjj:2,S", {st_mode=S_IFREG|0644, st_size=7150, ...}) = 0
open("/home/fietze/Mail/trash/cur/1271315469.4440.NyNjj:2,S", O_RDONLY) = 19
fstat(19, {st_mode=S_IFREG|0644, st_size=7150, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f784a1b3000
read(19, "Return-Path: <snr@lmv-hartmannsd"..., 4096) = 4096
read(19, "t: Re: Kernel headers\nReferences"..., 4096) = 3054
close(19)                               = 0
munmap(0x7f784a1b3000, 4096)            = 0
stat("/home/fietze/Mail/trash/cur/1271315472.4440.VxjtU:2,S", {st_mode=S_IFREG|0644, st_size=5848, ...}) = 0
stat("/home/fietze/Mail/trash/cur/1271315472.4440.VxjtU:2,S", {st_mode=S_IFREG|0644, st_size=5848, ...}) = 0
open("/home/fietze/Mail/trash/cur/1271315472.4440.VxjtU:2,S", O_RDONLY) = 19


My trash folder has about 30000 mails in it and is set up to expire mails after 365 days.

I could not see tat behaviour with older versions of KDE PIM. But I always had about those many mails in my trash, and trash was always set up to expire.
Comment 1 Martin Buerger 2010-07-01 22:52:42 UTC
Same here. I just upgraded from 4.2 to 4.4.4 (Gentoo x86) and every time I pull emails from my POP3 accounts kmail starts accessing/reading old emails. I used iotop and it showed a constant reading performance of around 1MB/sec and lsof showed me that kmail runs through my local mail folders.
Comment 2 Martin Buerger 2010-07-01 23:00:13 UTC
Well, not _everytime_ but each time I start KDE and after that the first time I use kmail to fetch my emails it shows the behaviour as described above. Subsequent attempts work without showing this strange disk-load.
Comment 3 Martin Buerger 2011-05-17 07:04:27 UTC
In my case this was related to a previously executed search, hence, if the search returned a lot of emails then the next time the same search is being executed. In order to avoid this behaviour - at least for vast search results - I made another search in a small mail folder with no hits. After another restart of KDE kmail worked without showing any of the above mentioned signs.
Comment 4 Christophe Marin 2011-05-18 14:22:07 UTC
*** Bug 251240 has been marked as a duplicate of this bug. ***
Comment 5 Christophe Marin 2011-05-18 14:22:41 UTC
*** Bug 232047 has been marked as a duplicate of this bug. ***
Comment 6 Peer Heinlein 2011-05-18 22:25:05 UTC
Today I met Till Adam from KDAB and we debugged my slow kmail. Looks like the major problem is, that kmail writes his kmailrc *** very *** often. On the one hand this needs a lot of CPU (1,7 Mbyte file, generating 70.000 lines config), on the other hand this is done using fsync(), so there's very much I/O.

I'll receive a patch for this during the next days, maybe all the problems are gone then...
Comment 7 bjoernv 2012-08-31 21:16:54 UTC
I found, that especially Xorg uses a lot of CPU time, if kmail starts reading mail folders. May be, that there are too much screen updates during reading mail folders.

Test: openSUSE 12.1, KDE 4.9,
Comment 8 BRULE Herman 2012-08-31 21:26:21 UTC
I had same problem with ultracopier, I have solved it with using MVC of Qt.
Comment 9 Myriam Schweingruber 2012-09-02 07:14:38 UTC
Moving to kmail2
Comment 10 Denis Kurz 2016-09-24 18:12:00 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 11 Denis Kurz 2017-01-07 22:28:06 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.