| Summary: | kmail or kontact using a lot of CPU and disk when starting reading mail folders | ||
|---|---|---|---|
| Product: | [Applications] kmail2 | Reporter: | Roman Fietze <kde> |
| Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | CC: | alpha_one_x86, bjoernv, f.leerink, mbuerger, p.heinlein |
| Priority: | NOR | ||
| Version: | 4.9.0 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Unspecified | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
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. 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. 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. *** Bug 251240 has been marked as a duplicate of this bug. *** *** Bug 232047 has been marked as a duplicate of this bug. *** 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... 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, I had same problem with ultracopier, I have solved it with using MVC of Qt. Moving to kmail2 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. 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. |
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.