With 1.2.11 and mbox storage, the delay time in pulling new mail headers to the client from imap folders seems to be directly proportional to mailbox size, regardless of the number of new messages. At present, if the mailbox is large, pulling new headers is rather painfully slow. Is this expected behavior? Especially given that the client already has all the "old" mails in the folder cached, and thus wouldn't be asking for them? Is there a setting(s) I can change to optimize/fix this? -- Stan
On 2010-05-27 1:03 AM, Stan Hoeppner wrote:> With 1.2.11 and mbox storage, the delay time in pulling new mail > headers to the client from imap folders seems to be directly > proportional to mailbox size, regardless of the number of new > messages. At present, if the mailbox is large, pulling new headers is > rather painfully slow. > > Is this expected behavior? Especially given that the client already > has all the "old" mails in the folder cached, and thus wouldn't be > asking for them? > > Is there a setting(s) I can change to optimize/fix this?Stan, I think you're the only one experiencing this, otherwise there would be a lot more noise on this list about it... At least, I'm not, with 1.2.11 and TB3... Did you ever follow the TB specific troubleshooting steps IU pointed you to to troubleshoot the TB connections, to see what it is doing? -- Best regards, Charles
On Thu, 2010-05-27 at 00:03 -0500, Stan Hoeppner wrote:> With 1.2.11 and mbox storage, the delay time in pulling new mail headers to > the client from imap folders seems to be directly proportional to mailbox > size, regardless of the number of new messages. At present, if the mailbox is > large, pulling new headers is rather painfully slow.See if mbox_very_dirty_syncs=yes helps.
Timo Sirainen put forth on 5/27/2010 9:37 AM:> On Thu, 2010-05-27 at 00:03 -0500, Stan Hoeppner wrote: >> With 1.2.11 and mbox storage, the delay time in pulling new mail headers to >> the client from imap folders seems to be directly proportional to mailbox >> size, regardless of the number of new messages. At present, if the mailbox is >> large, pulling new headers is rather painfully slow. > > See if mbox_very_dirty_syncs=yes helps.Yes Timo, initial use after enabling this seems to have helped dramatically. The wait time on my 13k+ folder seems to have dropped from about 10 seconds to less than 1 second. Thank you for the suggestion. What, if anything, am I sacrificing, or what new problems might I cause, by using mbox_very_dirty_syncs=yes? Previously I was using mbox_dirty_syncs = yes. -- Stan
On Thu, 2010-05-27 at 20:14 -0500, Stan Hoeppner wrote:> What, if anything, am I sacrificing, or what new problems might I cause, by > using mbox_very_dirty_syncs=yes? Previously I was using mbox_dirty_syncs = yes.If non-Dovecot MUAs modify mbox simultaneously (except appends by MDA are ok), Dovecot might not notice those changes immediately and it might log some errors sometimes.
Reasonably Related Threads
- Thunderbird very slow startup, 1.2.11, mbox, postfix local delivery to /var/mail
- Dovecot 1.0-stable mbox performance and disconnections
- Sieve problem. Timo, is this mbox file size limitation hard coded? If so, why?
- Multiple Concurrent IMAP Connections For Same User
- remote hot site, IMAP replication or cluster over WAN