If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

IMAP 'fetch 1:*' for many folders at once overloads IMAP server

RESOLVED WONTFIX

Status

Thunderbird
General
--
major
RESOLVED WONTFIX
11 years ago
9 years ago

People

(Reporter: Per Reedtz Thomsen, Unassigned)

Tracking

({perf})

PowerPC
Mac OS X

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

When I launch and login to 2.0B1, the client issues requests to the server to retrieve all messages from several folders at the same time AFAICT.

I see requests like this (from ethereal):

IMAP Request: 18 select "CheapWine Approvals"
IMAP Request: 19 UID fetch 1:* (FLAGS)
IMAP Request: 20 IDLE
IMAP Request: 21 select "Junk"
IMAP Request: 22 UID fetch 1:* (FLAGS)
.
.
.

This is different behavior from how 1.5.0.x works, and this is causing massive load problems on my (admittedly aging, but still quite capable dual-processor mail server). I ran TB 2.0b1 for 15 hours, and after about 4 hrs, the load was up to 50, all due to highly busy imapd processes. iowait was the killer, eventually taking 180% of the CPUs' time.

I'm not sure what the purpose of this 'full download' of all the messages is, but if there was a way to prioritize this task down, that would mean that I would be able to run TB2 against my imap server.


Reproducible: Always

Steps to Reproduce:
1. Start TB2.0b1
2. Login to imap account.
3. Watch load increase on server, as more folders are being retrieved.

Actual Results:  
Load increases on server, due to the imapd processes spawned from TB2.0b1

Expected Results:  
The load profile that TB2 exhibits should be almost identical to the TB1.5 load profile.
(Reporter)

Comment 1

11 years ago
A few more details:

Even though prefs tell TB to move spam to the Junk folder, this doesn't happen. Also, drag-dropping messages onto folders in the folder list has no effect. 

Wondering if this is related?
(Reporter)

Comment 2

11 years ago
version not set.
Version: unspecified → 2.0
(Reporter)

Comment 3

11 years ago
More test data: Created a brand new profile, and copied over the filters from my old profile.

Problem remains. After about 30 minutes, the load was already up to 3 on my server. After quitting TB, load dropped back to 0.2 or so.

Comment 4

11 years ago
Just a wild guess, but is the "full download" used so new message notifications can display body content? Does turning the notifications off make a difference?

Comment 5

11 years ago
if you look at the folder properties for those folders, are they configured to be checked for new messages? Or are they getting messages moved to them by imap filters on your inbox? If the latter, yes, we're trying to get the preview text for the new messages, and you can turn off the preview text feature, if you don't want us to do that.

Comment 6

11 years ago
how many active connections is TB making? We shouldn't be keeping more than five connections open in any case, and you can reduce that number in the advanced settings for the imap server. But once you've got five connections open, we should be switching between them, and there shouldn't be an increase in idle load.
(Reporter)

Comment 7

11 years ago
(In reply to comment #5)
> if you look at the folder properties for those folders, are they configured to
> be checked for new messages? Or are they getting messages moved to them by imap
> filters on your inbox? If the latter, yes, we're trying to get the preview text
> for the new messages, and you can turn off the preview text feature, if you
> don't want us to do that.

Only the inbox is configured to be checked for new messages, but I have a boatload of filters, and whenever new mail arrives, a lot of stuff gets shuffled off to a wide variety of folders, so that is why TB is trying to retrieve mail from all manner of folders. I can understand that.

I don't really want to turn off the preview text thingie, and I presume this is a one-time thing as the folders are downloaded, and only incremental data will be downloaded after that.


(In reply to comment #6)
> how many active connections is TB making? We shouldn't be keeping more than
> five connections open in any case, and you can reduce that number in the
> advanced settings for the imap server. But once you've got five connections
> open, we should be switching between them, and there shouldn't be an increase
> in idle load.

As I've been writing this response (45 minutes including interruptions, etc.), the number of imapd processes for my user on my server has risen from 5 to 15, and the load on the server has increased from 0.5 to just under 13.

I checked the advanced settings and the max connections limit is indeed 5. Doesn't seem to be heeded. Maybe the filtering code that moves to another folder is the culprit?

Comment 8

11 years ago
I'm pretty sure the connection cache count is heeded - however, it's per account, so if you have multiple accounts all configured to point to the same server, you can get more connections going.

netstat should tell you how many connections the client thinks it has to the server. If all else fails, an imap protocol log might help (though it will be large)

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Re the one-time-ness of this - yes and no. If we happen to be re-using a cached connection, then yes, we'll just download the new headers, and not refetch all the flags. But, if we have to switch folders on a connection, then we have to refetch the flags...so, it may actually pay to increase the number of cached connections - it just depends on how efficiently your server handles connections.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 9

11 years ago
OK... There is only one account pointing to this server, and I made doubly sure by creating a brand new profile. This is currently connected to 8 imapd processes on my server (load 4.44).

I will start the protocol log and report back later today. Just wanted to let you know that the client is connecting more times than allowed by the connection cache count. I'm just letting the client sit, so the reason for the increase in activity is all about new mail being filtered.
(Reporter)

Comment 10

11 years ago
Not sure this is related at all, but quitting caused a crash. Talkback incident #TB27794182Z

Probably not related, but just thought I'd mention it.

Comment 11

11 years ago
Per, what does netstat | grep imap tell you about how many connections the client thinks are open, and the state of the connections?
(Reporter)

Comment 12

11 years ago
OK... Here is what I found: The client seems to keep itself within the 5 connections:

curie:~ [147] netstat -t | grep imap
tcp4       0      0  a.b.c.d.57450  mostro.reedtz.co.imap  ESTABLISHED
tcp4       0      0  a.b.c.d.57209  mostro.reedtz.co.imap  ESTABLISHED
tcp4       0      0  a.b.c.d.56468  mostro.reedtz.co.imap  ESTABLISHED
tcp4       0      0  a.b.c.d.54195  mostro.reedtz.co.imap  ESTABLISHED

The server sees things a little differently:
[root@mostro log]# netstat -t | grep imap | grep curie
tcp        1      0 mostro.reedtz.com:imap      curie.reedtz.com:57209      CLOSE_WAIT  
tcp        0      0 mostro.reedtz.com:imap      curie.reedtz.com:56863      ESTABLISHED 
tcp        0      0 mostro.reedtz.com:imap      curie.reedtz.com:54195      ESTABLISHED 
tcp        0    431 mostro.reedtz.com:imap      curie.reedtz.com:56473      LAST_ACK    
tcp        1      0 mostro.reedtz.com:imap      curie.reedtz.com:56727      CLOSE_WAIT  
tcp        0      0 mostro.reedtz.com:imap      curie.reedtz.com:56468      ESTABLISHED 
tcp        0      0 mostro.reedtz.com:imap      curie.reedtz.com:56825      ESTABLISHED 

So, three more processes hanging around, waiting to die. I looked in the logs of the imap server, and found many instances of the following:

[root@mostro log]# grep "\[30763\]" maillog
Dec 27 14:08:48 mostro imapd[30763]: imap service init from a.b.c.d
Dec 27 14:08:48 mostro imapd[30763]: Authenticated user=pthomsen host=curie.reedtz.com [a.b.c.d]
Dec 27 14:10:22 mostro imapd[30763]: Killed (lost mailbox lock) user=pthomsen host=curie.reedtz.com [a.b.c.d]

This repeats itself over and over again.

imapd processes: 
31292 pthomsen  18   0 18308  16m  840 D  8.3  1.6   0:11.34 imapd                                                                  31737 pthomsen  18   0 20152  18m  840 R  6.3  1.8   0:13.26 imapd                                                                  30763 pthomsen  18   0 23396  21m  840 D  5.3  2.1   0:16.68 imapd                                                                  26566 pthomsen  15   0  2636 1084  888 S  0.0  0.1   0:00.26 imapd                                                                  29715 pthomsen  15   0  3064 1572  868 S  0.0  0.2   0:03.18 imapd                                                                  31789 pthomsen  16   0  2516  948  828 S  0.0  0.1   0:00.01 imapd                                                                  31790 pthomsen  16   0  2516  944  828 S  0.0  0.1   0:00.02 imapd  

Could it be something like this: For whatever reason an imapd process takes too long to respond, and the client ditches it; it however continues its work, until it tries to respond back, and then dies. This could take a long time, especially if TB has spun up another process to do the exact same work. This will simply perpetuate itself into perpetuity... 

As I said, I will run the protocol logs when I have some more time tonight. I briefly tried it, but thunderbird-bin kept segv'ing on me. Crash log seems to indicate that it can't load some dynamic libs... Will look at this some more tonight.
(Reporter)

Comment 13

11 years ago
The process listing is unreadable... Here is one that should be better:

31292 pthomsen  18   0 18308  16m  840 D  8.3  1.6   0:11.34 imapd
31737 pthomsen  18   0 20152  18m  840 R  6.3  1.8   0:13.26 imapd                                    
30763 pthomsen  18   0 23396  21m  840 D  5.3  2.1   0:16.68 imapd   
26566 pthomsen  15   0  2636 1084  888 S  0.0  0.1   0:00.26 imapd            
29715 pthomsen  15   0 3064  1572  868 S  0.0  0.2   0:03.18 imapd 
31789 pthomsen  16   0  2516  948  828 S  0.0  0.1   0:00.01 imapd                                                                 
31790 pthomsen  16   0  2516  944  828 S  0.0  0.1   0:00.02 imapd  

Comment 14

11 years ago
TB has a two minute timeout - if the server doesn't respond with two minutes with some data, we will assume the server has gone away - you can increase that timeout under the advanced options, I believe.  However, two minutes is an awfully long time for the server not to respond. What kind of mail server is it? If it's a Courier server, it might be limiting you to four connections per ip address, though you'd usually get an error message from TB about that...
(Reporter)

Comment 15

11 years ago
Did not get to the protocol log tonight, because I was trying to upgrade my IMAP server software (UW imapd) to the latest and greatest (2006d). 

Once I have done that, I will run the protocol log. I'm upgrading to the latest software, to make sure that the new way in which TB interacts with the server doesn't expose some already solved problem in the UW server.

So, it will probably be a day or so before I will be able to run the protocol log.
(Reporter)

Comment 16

11 years ago
I'm trying to get a protocol log to see what's going on, but I can't get it to work. I followed the instructions in the link in comment #8, but when I run TB, it segv's.

A truncated crash report:

Host Name:      curie
Date/Time:      2006-12-29 00:11:35.843 -0800
OS Version:     10.4.8 (Build 8L127)
Report Version: 4

Command: thunderbird-bin
Path:    /Applications/tb2/Thunderbird.app/Contents/MacOS/thunderbird-bin
Parent:  tcsh [7454]

Version: 2.0b1 (2.0b1)

PID:    10786
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xbf7ffff0

Thread 0 Crashed:
0   dyld        0x8fe12164 ImageLoaderMachO::findExportedSymbol(char const*, void const*, bool, ImageLoader**) const + 48
1   dyld        0x8fe125ac ImageLoaderMachO::findExportedSymbol(char const*, void const*, bool, ImageLoader**) const + 1144
2   dyld        0x8fe125ac ImageLoaderMachO::findExportedSymbol(char const*, void const*, bool, ImageLoader**) const + 1144
.
.
.
507 dyld        0x8fe125ac ImageLoaderMachO::findExportedSymbol(char const*, void const*, bool, ImageLoader**) const + 1144
508 dyld        0x8fe125ac ImageLoaderMachO::findExportedSymbol(char const*, void const*, bool, ImageLoader**) const + 1144

Thread 0 crashed with PPC Thread State 64:
  srr0: 0x000000008fe12164 srr1: 0x100000000000d030                        vrsave: 0x0000000000000000
    cr: 0x44002202          xer: 0x0000000000000000   lr: 0x000000008fe12140  ctr: 0x000000008fe12134
    r0: 0x000000008fe125ac   r1: 0x00000000bf8000d0   r2: 0x0000000044002202   r3: 0x000000000190ed50
    r4: 0x000000008fd36a8c   r5: 0x0000000000000000   r6: 0x0000000000000001   r7: 0x00000000bfffeaa8
    r8: 0x000000000000002d   r9: 0x0000000000000006  r10: 0x000000008fd36a8b  r11: 0x000000008fd36a8d
   r12: 0x000000008fe12134  r13: 0x00000000000012b4  r14: 0x00000000a34b8d25  r15: 0x0000000000001000
   r16: 0x0000000000000000  r17: 0x000000008fe5b558  r18: 0x0000000000000001  r19: 0x000000008fd29fc4
   r20: 0x0000000000000001  r21: 0x0000000000000000  r22: 0x000000008fd2ca64  r23: 0x0000000000000000
   r24: 0x0000000000000001  r25: 0x000000008fd36a8c  r26: 0x00000000bfffeaa8  r27: 0x0000000000000000
   r28: 0x000000000190ed50  r29: 0x0000000000000003  r30: 0x0000000000000078  r31: 0x000000008fe12140

Then a listing of the dylibs in the binary image.

I searched bugzilla for a bug related to this, but didn't find anything.

Help!
(Reporter)

Comment 17

11 years ago
Did a bunch more tests, with the new UW imap server. I used ethereal for my tests, as I still can't get protocol logging to work on the client.

The problem shows itself when trying to move filtered mail to a large (~150K messages) folder on the IMAP server, and requesting all the flags for it [fetch 1:* (FLAGS)]. This kills the old UW server (it's using old style Unix mail files).

Upgrading the server, and converting these huge mail files to MBX, combined with a lot of patience got rid of the problem on my server.

Again, I don't think my server is the slowest IMAP server out there, so it might be useful to have some defensive code in place to deal with the issues I have been seeing. 

And for those of you saying that this is a problem with my server, and not a TB bug, I just want to note again, that TB 1.5 had no problems interacting with my crusty old server... 2.0 on the other hand wreaked havoc. And when 2.0 gets installed en masse, you could have a lot of unhappy ISPs, because the load profile of TB will be different.

My $0.02...

Comment 18

11 years ago
I don't know about the crash - it seems unrelated, but I just don't have enough information.

We've given people the option of turning off the preview text feature, which should get you back to the 1.5 behavior. We're doing what we have to do to get that information. I know you don't want me to complain about your server, but the UW server using the mbox format slows down a bit on 150K message folders :-) As does Thunderbird :-)
(Reporter)

Comment 19

11 years ago
Not to beat a dead horse here (and I agree that trying to fetch the flags for 150K messages will be slow), but this is a new behavior that will not be obvious to the average user... All they will see is that TB2 'doesn't work'... 

I'm fine with the option to turn off preview text. I'm going to try to turn it off, to see if I get back to a 1.5 speed of server interaction. 
(Reporter)

Comment 20

11 years ago
Just a note on the latest updated version. (About says: version 2.0.0.0 (20070326))

I have similar experiences again, using the latest build. When I start TB up now, the load shoots up again on my IMAP server (load of 5+), for about 10-15 minutes, after which time things are OK again. Lotsa imapd processes, and iowait sky-rockets. I have upgraded all folders to use the indexed MBX format for UW imapd.

I did not use ethereal again to look at the sessions, but if you need the data, I'll do it.

Just noting this, don't expect an answer. Seems like something changed in this update. Didn't want that bit of info to get lost.
(Reporter)

Comment 21

11 years ago
Spoke too soon... The problem is back now, just as it was before I upgraded my IMAP server.

Right now, I have 38 imapd processes running for me on the server, and the load is ~4. 

'mail.showPreviewText' is set to false.

I will run ethereal, when I get a minute to give more detail.
(Reporter)

Comment 22

11 years ago
Here is some ethereal output. It seems that even though the showPreviewText pref is set to false, the 'UID fetch 1:*' seems to be prevalent...

Is this a new thing in 2.0 proper?

[root@mostro username]# tethereal -R "ip.src == a.b.c.d and imap.request == true"
Capturing on eth0
  9.465194 a.b.c.d -> w.x.y.z IMAP Request: 1 capability
 15.619526 a.b.c.d -> w.x.y.z IMAP Request: 2 login "username" "XXXXXXXX"
 15.632516 a.b.c.d -> w.x.y.z IMAP Request: 3 namespace
 15.636604 a.b.c.d -> w.x.y.z IMAP Request: 4 lsub "" "*"
 15.788595 a.b.c.d -> w.x.y.z IMAP Request: 5 lsub "" "#mhinbox*"
 15.791835 a.b.c.d -> w.x.y.z IMAP Request: 6 lsub "" "#mh/*"
 15.794768 a.b.c.d -> w.x.y.z IMAP Request: 7 lsub "" "~*"
 15.798048 a.b.c.d -> w.x.y.z IMAP Request: 8 lsub "" "#shared/*"
 15.800943 a.b.c.d -> w.x.y.z IMAP Request: 9 lsub "" "#ftp/*"
 15.804034 a.b.c.d -> w.x.y.z IMAP Request: 10 lsub "" "#news.*"
 15.806939 a.b.c.d -> w.x.y.z IMAP Request: 11 lsub "" "#public/*"
 15.809849 a.b.c.d -> w.x.y.z IMAP Request: 12 list "" "INBOX"
 15.821088 a.b.c.d -> w.x.y.z IMAP Request: 13 select "INBOX"
 15.831730 a.b.c.d -> w.x.y.z IMAP Request: 1 capability
 15.833361 a.b.c.d -> w.x.y.z IMAP Request: 2 login "username" "XXXXXXXX"
 15.846547 a.b.c.d -> w.x.y.z IMAP Request: 3 list "" "Lists"
 15.856533 a.b.c.d -> w.x.y.z IMAP Request: 4 list "" "Personal"
 15.863716 a.b.c.d -> w.x.y.z IMAP Request: 5 list "" "Stats"
 16.234512 a.b.c.d -> w.x.y.z IMAP Request: 14 UID fetch 1:* (FLAGS)
 16.444103 a.b.c.d -> w.x.y.z IMAP Request: 15 UID fetch 912357:912361,912363:912367,912370,912372,912376,912378:912415 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type Received-SPF Reply-To X-Spam-Flag)])
 30.228738 a.b.c.d -> w.x.y.z IMAP Request: 16 uid store 912380 +Flags (\Seen)
 30.233965 a.b.c.d -> w.x.y.z IMAP Request: 17 uid store 912398 +Flags (\Seen)
 30.240679 a.b.c.d -> w.x.y.z IMAP Request: 19 uid copy 912357:912361,912366:912367,912372,912378,912381:912383,912386:912388,912393:912394,912396,912401,912409:912410,912413:912414 "Tech/Fedora"
 73.294729 a.b.c.d -> w.x.y.z IMAP Request: 20 uid store 912357:912361,912366:912367,912372,912378,912381:912383,912386:912388,912393:912394,912396,912401,912409:912410,912413:912414 +FLAGS (\Deleted \Seen)
 73.519341 a.b.c.d -> w.x.y.z IMAP Request: 1 capability
 73.520963 a.b.c.d -> w.x.y.z IMAP Request: 22 uid copy 912363:912364,912404,912406 "Trash"
 73.522132 a.b.c.d -> w.x.y.z IMAP Request: 2 login "username" "XXXXXXXX"
 73.535971 a.b.c.d -> w.x.y.z IMAP Request: 3 select "Tech/Fedora"
134.733182 a.b.c.d -> w.x.y.z IMAP Request: 1 capability
134.734394 a.b.c.d -> w.x.y.z IMAP Request: 1 capability
134.737238 a.b.c.d -> w.x.y.z IMAP Request: 2 login "username" "XXXXXXXX"
134.739206 a.b.c.d -> w.x.y.z IMAP Request: 2 login "username" "XXXXXXXX"
134.880721 a.b.c.d -> w.x.y.z IMAP Request: 3 select "INBOX"
134.906588 a.b.c.d -> w.x.y.z IMAP Request: 3 select "Tech/Fedora"
136.983295 a.b.c.d -> w.x.y.z IMAP Request: 4 UID fetch 1:* (FLAGS)
137.042155 a.b.c.d -> w.x.y.z IMAP Request: 5 expunge
137.131350 a.b.c.d -> w.x.y.z IMAP Request: 6 UID fetch 912363:912365,912370,912376,912379:912380,912384:912385,912390,912392,912398:912400,912404,912406 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type Received-SPF Reply-To X-Spam-Flag)])
137.295806 a.b.c.d -> w.x.y.z IMAP Request: 8 uid copy 912363:912364,912404,912406 "Trash"
195.579664 a.b.c.d -> w.x.y.z IMAP Request: 1 capability
195.581031 a.b.c.d -> w.x.y.z IMAP Request: 2 login "username" "XXXXXXXX"
195.594501 a.b.c.d -> w.x.y.z IMAP Request: 3 select "Tech/Fedora"
197.607950 a.b.c.d -> w.x.y.z IMAP Request: 1 capability
197.609275 a.b.c.d -> w.x.y.z IMAP Request: 2 login "username" "XXXXXXXX"
197.622162 a.b.c.d -> w.x.y.z IMAP Request: 3 select "INBOX"
198.794029 a.b.c.d -> w.x.y.z IMAP Request: 4 UID fetch 1:* (FLAGS)
198.808319 a.b.c.d -> w.x.y.z IMAP Request: 5 UID fetch 912363:912365,912370,912376,912379,912384:912385,912390,912392,912399:912400,912404,912406 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type Received-SPF Reply-To X-Spam-Flag)])
198.848299 a.b.c.d -> w.x.y.z IMAP Request: 7 uid copy 912363:912364,912404,912406 "Trash"
(Reporter)

Comment 23

11 years ago
And, for completeness sake, here is the ethereal output from 2.0b2. notice that there is only one instance of 'fetch 1:* (FLAGS)', for INBOX.

[root@mostro username]# tethereal -R "ip.src == a.b.c.d and imap.request == true"
Capturing on eth0
  1.585755 a.b.c.d -> w.x.y.z IMAP Request: 2 login "username" ""
 10.912731 a.b.c.d -> w.x.y.z IMAP Request: 3 login "username" "XXXXXXXX"
 10.929824 a.b.c.d -> w.x.y.z IMAP Request: 4 namespace
 10.935106 a.b.c.d -> w.x.y.z IMAP Request: 5 lsub "" "*"
 11.025366 a.b.c.d -> w.x.y.z IMAP Request: 6 lsub "" "#mhinbox*"
 11.028161 a.b.c.d -> w.x.y.z IMAP Request: 7 lsub "" "#mh/*"
 11.030815 a.b.c.d -> w.x.y.z IMAP Request: 8 lsub "" "~*"
 11.033797 a.b.c.d -> w.x.y.z IMAP Request: 9 lsub "" "#shared/*"
 11.036430 a.b.c.d -> w.x.y.z IMAP Request: 10 lsub "" "#ftp/*"
 11.039164 a.b.c.d -> w.x.y.z IMAP Request: 11 lsub "" "#news.*"
 11.041798 a.b.c.d -> w.x.y.z IMAP Request: 12 lsub "" "#public/*"
 11.044447 a.b.c.d -> w.x.y.z IMAP Request: 13 list "" "INBOX"
 11.056614 a.b.c.d -> w.x.y.z IMAP Request: 14 select "INBOX"
 11.069859 a.b.c.d -> w.x.y.z IMAP Request: 1 capability
 11.071288 a.b.c.d -> w.x.y.z IMAP Request: 2 login "username" "XXXXXXXX"
 11.084798 a.b.c.d -> w.x.y.z IMAP Request: 3 list "" "Lists"
 11.098033 a.b.c.d -> w.x.y.z IMAP Request: 4 list "" "Personal"
 11.110295 a.b.c.d -> w.x.y.z IMAP Request: 5 list "" "Stats"
 11.453963 a.b.c.d -> w.x.y.z IMAP Request: 15 UID fetch 1:* (FLAGS)
 11.791638 a.b.c.d -> w.x.y.z IMAP Request: 16 UID fetch 912435,912437:912438,912441:912451 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type Received-SPF Reply-To X-Spam-Flag)])
 24.648816 a.b.c.d -> w.x.y.z IMAP Request: 18 uid copy 912435,912437:912438,912442,912446,912449 "Tech/Fedora"
 67.710981 a.b.c.d -> w.x.y.z IMAP Request: 19 uid store 912435,912437:912438,912442,912446,912449 +FLAGS (\Deleted \Seen)
 67.906654 a.b.c.d -> w.x.y.z IMAP Request: 21 uid copy 912443:912444 "Trash"
 82.079636 a.b.c.d -> w.x.y.z IMAP Request: 22 uid store 912443:912444 +FLAGS (\Deleted \Seen)
 82.103617 a.b.c.d -> w.x.y.z IMAP Request: 24 uid copy 912447:912448 "SpamF/SpamL"
125.487932 a.b.c.d -> w.x.y.z IMAP Request: 25 uid store 912447:912448 +FLAGS (\Deleted \Seen)
125.535234 a.b.c.d -> w.x.y.z IMAP Request: 27 uid copy 912450 "Tech/Samba"
144.858349 a.b.c.d -> w.x.y.z IMAP Request: 28 uid store 912450 +FLAGS (\Deleted \Seen)
144.908788 a.b.c.d -> w.x.y.z IMAP Request: 29 UID fetch 912441 (UID RFC822.SIZE BODY.PEEK[]<0.10240>)
144.920001 a.b.c.d -> w.x.y.z IMAP Request: 30 UID fetch 912441 (UID RFC822.SIZE BODY.PEEK[]<10240.6370>)
145.037666 a.b.c.d -> w.x.y.z IMAP Request: 31 UID fetch 912014 (UID RFC822.SIZE BODY[]<0.10240>)
145.049867 a.b.c.d -> w.x.y.z IMAP Request: 32 UID fetch 912014 (UID RFC822.SIZE BODY[]<10240.6512>)
145.668606 a.b.c.d -> w.x.y.z IMAP Request: 33 UID fetch 912445 (UID RFC822.SIZE BODY.PEEK[])
145.887311 a.b.c.d -> w.x.y.z IMAP Request: 34 UID fetch 912451 (UID RFC822.SIZE BODY.PEEK[])
147.059480 a.b.c.d -> w.x.y.z IMAP Request: 35 uid store 912441,912445,912451 +FLAGS (Junk)
147.091126 a.b.c.d -> w.x.y.z IMAP Request: 37 uid copy 912441,912445,912451 "Junk"
149.329990 a.b.c.d -> w.x.y.z IMAP Request: 38 uid store 912441,912445,912451 +FLAGS (\Deleted \Seen)
149.695147 a.b.c.d -> w.x.y.z IMAP Request: 39 IDLE
161.315180 a.b.c.d -> w.x.y.z IMAP Request: DONE
161.327992 a.b.c.d -> w.x.y.z IMAP Request: 40 UID fetch 912016 (UID RFC822.SIZE BODY[])
161.453641 a.b.c.d -> w.x.y.z IMAP Request: 41 IDLE
162.374892 a.b.c.d -> w.x.y.z IMAP Request: DONE
162.384588 a.b.c.d -> w.x.y.z IMAP Request: 42 UID fetch 912021 (UID RFC822.SIZE BODY[])
162.425466 a.b.c.d -> w.x.y.z IMAP Request: 43 check
162.525740 a.b.c.d -> w.x.y.z IMAP Request: 44 IDLE
162.962031 a.b.c.d -> w.x.y.z IMAP Request: DONE
162.963643 a.b.c.d -> w.x.y.z IMAP Request: 45 noop
162.964829 a.b.c.d -> w.x.y.z IMAP Request: 46 UID fetch 912452:* (FLAGS)
162.977946 a.b.c.d -> w.x.y.z IMAP Request: 47 UID fetch 912452:912455 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type Received-SPF Reply-To X-Spam-Flag)])
170.226620 a.b.c.d -> w.x.y.z IMAP Request: 48 uid store 912454 +FLAGS (box)
170.242471 a.b.c.d -> w.x.y.z IMAP Request: 50 uid copy 912452:912453 "Tech/Fedora"
207.749027 a.b.c.d -> w.x.y.z IMAP Request: 51 uid store 912452:912453 +FLAGS (\Deleted \Seen)
207.915732 a.b.c.d -> w.x.y.z IMAP Request: 52 UID fetch 912454 (UID RFC822.SIZE BODY.PEEK[])
208.278191 a.b.c.d -> w.x.y.z IMAP Request: 53 uid store 912454 +Flags (\Seen)
208.296851 a.b.c.d -> w.x.y.z IMAP Request: 54 uid store 912454 +FLAGS (NonJunk)
208.299362 a.b.c.d -> w.x.y.z IMAP Request: 55 IDLE 

Updated

9 years ago
Assignee: mscott → nobody
David, given no other cc: nor dupes it would seem this is not a widespread problem. Given the workaround of user scaling back "preview text feature", is there any reasonable change for Thunderbird to address this, i.e. is there a way forward?  (it sounds like not)  Or do we close this invalid / server issue?
Severity: critical → major
Keywords: perf
(Reporter)

Comment 25

9 years ago
As for me, specifically, I have (just recently) upgraded my mail server to a screaming dual quad-core beast, so I'm not seeing this anymore. Also, I'm not running UW imapd anymore, but rather dovecot.

I think we can close this. Even while I was still running UW imapd on the old (slow), after 2.0 this behavior diminished significantly.

Comment 26

9 years ago
I think resolving this as wontfix is the way to go.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.