Bug 96954 - high loads when accessing IMAP folders
Summary: high loads when accessing IMAP folders
Status: RESOLVED REMIND
Alias: None
Product: kmail
Classification: Applications
Component: IMAP (show other bugs)
Version: 1.7.2
Platform: Slackware Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2005-01-13 22:10 UTC by mirceab
Modified: 2008-11-07 17:19 UTC (History)
2 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 mirceab 2005-01-13 22:10:35 UTC
Version:            (using KDE KDE 3.3.2)
Installed from:    Slackware Packages
OS:                Linux

After upgrading to KDE 3.3.2 I noticed the weird behavior in KMail. Sometimes, not always, when accessing the emails from an IMAP account, the processor is 100% utilized.

When this happens, the email body is not displayed in the email frame (in the main kmail window), and the only way to see it is to double click the message in the message list to open a separate window.

vmstat 1 looks like:
----------------
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 1  0   1396  21320  37304 104744    0    0     8    10   18     8  2  1 97  0
 1  0   1396  21368  37304 104744    0    0     0     0 1006   374 71 29  0  0
 1  0   1396  21368  37304 104744    0    0     0     0 1002   429 75 25  0  0
 1  0   1396  21368  37304 104744    0    0     0   216 1047   346 72 28  0  0
 1  0   1396  21368  37304 104744    0    0     0     0 1004   336 69 31  0  0
 1  0   1396  21384  37312 104744    0    0     0    36 1008   347 72 28  0  0
 1  0   1396  21384  37312 104744    0    0     0     0 1003   347 70 30  0  0
 1  0   1396  21384  37312 104744    0    0     0     0 1004   333 71 29  0  0
 1  0   1396  21384  37312 104744    0    0     0   536 1100   398 68 32  0  0
 1  0   1396  21384  37312 104744    0    0     0     0 1003   407 71 29  0  0
 1  0   1396  21384  37312 104744    0    0     0     0 1002   329 73 27  0  0
 1  0   1396  21384  37312 104744    0    0     0     0 1004   342 70 30  0  0
 1  0   1396  21384  37312 104744    0    0     0     0 1002   333 69 31  0  0
 1  0   1396  21384  37312 104744    0    0     0   184 1029   345 70 30  0  0
 1  0   1396  21384  37312 104744    0    0     0     0 1002   335 69 31  0  0
 1  0   1396  21384  37312 104744    0    0     0     0 1004   429 72 28  0  0
 1  0   1396  21384  37312 104744    0    0     0     0 1002   356 68 32  0  0
 1  0   1396  21384  37312 104744    0    0     0     0 1004   346 72 28  0  0
 1  0   1396  21384  37312 104744    0    0     0     4 1004   347 72 28  0  0
 1  0   1396  21384  37312 104744    0    0     0     0 1004   332 69 31  0  0
 1  0   1396  21384  37312 104744    0    0     0     0 1002   339 72 28  0  0
 9  0   1396  21368  37312 104744    0    0     0     0 1197   638 72 28  0  0
 1  0   1396  21368  37312 104744    0    0     0     0 1311  1307 75 25  0  0
 1  0   1396  21368  37316 104744    0    0     0     4 1165   916 75 25  0  0
 1  0   1396  21216  37360 104748    0    0     0  1424 1237  1974 83  8  1  8
 0  0   1396  27488  37364 104744    0    0     0   124 1126   596 33  2 65  0
 0  0   1396  27488  37364 104744    0    0     0     0 1203   591  7  0 93  0
 0  0   1396  27488  37364 104744    0    0     0     0 1003   328  1  0 99  0
 0  0   1396  27488  37368 104744    0    0     0    56 1004   427  0  0 100  0
 0  0   1396  27504  37368 104744    0    0     0     0 1007   354  1  0 99  0
 0  0   1396  27504  37376 104744    0    0     0    48 1005   345  0  0 100  0
 0  0   1396  27504  37376 104744    0    0     0     0 1202   600  4  4 92  0
 0  0   1396  27504  37376 104744    0    0     0     0 1009   339  1  0 99  0
 0  0   1396  27520  37376 104744    0    0     0     0 1083   448  3  1 96  0
 0  0   1396  27520  37376 104744    0    0     0     0 1023   363  1  0 99  0
 0  0   1396  27520  37376 104744    0    0     0     0 1022   442  1  0 99  0
 0  0   1396  27520  37376 104744    0    0     0     0 1010   360  1  0 99  0
 0  0   1396  27536  37376 104744    0    0     0     0 1009   347  1  1 98  0
 0  0   1396  27536  37376 104744    0    0     0     0 1004   346  1  0 99  0
 0  0   1396  27536  37376 104744    0    0     0     0 1003   336  0  0 100  0
-------------

(I have quit kmail while running vmstat, that's why you can see the CPU being unused after a while.)

I tried running kmail with strace and I noticed that when the load is high there a a lot of get calls to gettimeofday and select (on the imap Inbox file: ~/.kde/share/apps/kmail/imap/.41122546.directory/.Inbox.index.ids).

-----------
gettimeofday({1105648606, 330107}, NULL) = 0
select(17, [3 4 5 6 8 13 15 16], [], [], {0, 0}) = 0 (Timeout)
gettimeofday({1105648606, 330449}, NULL) = 0
gettimeofday({1105648606, 330524}, NULL) = 0
ioctl(4, FIONREAD, [0])                 = 0
gettimeofday({1105648606, 330699}, NULL) = 0
select(17, [3 4 5 6 8 13 15 16], [], [], {0, 0}) = 0 (Timeout)
gettimeofday({1105648606, 331034}, NULL) = 0
gettimeofday({1105648606, 331114}, NULL) = 0
ioctl(4, FIONREAD, [0])                 = 0
gettimeofday({1105648606, 331258}, NULL) = 0
select(17, [3 4 5 6 8 13 15 16], [], [], {0, 0}) = 0 (Timeout)
gettimeofday({1105648606, 331602}, NULL) = 0
gettimeofday({1105648606, 331677}, NULL) = 0
ioctl(4, FIONREAD, [0])                 = 0
gettimeofday({1105648606, 331821}, NULL) = 0
select(17, [3 4 5 6 8 13 15 16], [], [], {0, 0}) = 0 (Timeout)
gettimeofday({1105648606, 332148}, NULL) = 0
gettimeofday({1105648606, 332222}, NULL) = 0
ioctl(4, FIONREAD, [0])                 = 0
gettimeofday({1105648606, 332363}, NULL) = 0
select(17, [3 4 5 6 8 13 15 16], [], [], {0, 0}) = 0 (Timeout)
gettimeofday({1105648606, 332704}, NULL) = 0
gettimeofday({1105648606, 332778}, NULL) = 0
ioctl(4, FIONREAD, [0])                 = 0
-----------

Grepping for "gettimeofday({<time>" in the strace output I counted about 2500 call each second. e.g:

$ grep "gettimeofday({1105648597" kmail.strace | wc -l
2396
$ grep "gettimeofday({1105648598" kmail.strace | wc -l
2960
$ grep "gettimeofday({1105648599" kmail.strace | wc -l
2375
$ grep "gettimeofday({1105648600" kmail.strace | wc -l
2403

I never had this problem before KDE 3.3.2, and nothing changes on the IMAP server. I don't see any traffic between the my workstation and the IMAP server when the problem appears.

Let me know what other information might be usefull to identify the problem.

Thanks,
Mircea Baciu
Comment 1 Carsten Burghardt 2005-01-13 22:14:33 UTC
Hard to debug this but you could check kdepim 3.4 (once it's out) or the betas 
to see if you have the same problem.

Comment 2 schmid 2005-03-14 15:48:06 UTC
I have this problem now on KDE 3.4 RC1..which kmail 1.8.  Same exact issue.  I build from konstruct on top of Novell Linux Desktop .  The CPU get's pegged.. I staced the processes and it just continues to spit out:
gettimeofday({1110811252, 117265}, NULL) = 0
gettimeofday({1110811252, 119800}, NULL) = 0
gettimeofday({1110811252, 122494}, NULL) = 0
Comment 3 Shem Valentine 2008-09-14 22:38:29 UTC
I am having a hard time reproducing this, however you did mention that it only happens sometimes.  During my tests gettimeofday seemed to stay pretty low.  Are you still experiencing this issue? If so, you seem to be able to reproduce it, could you post your process?
Comment 4 Michael Leupold 2008-11-07 17:19:32 UTC
I'm closing this for now as it doesn't seem reproducible and is likely to be fixed. Please reopen if the problem is still reproducible for you.