[Dovecot] 1.2.11, mbox, new mail
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
Charles Marcus put forth on 5/27/2010 7:22 AM:
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...
Possibly I'm the only one using mbox storage with 13k+ emails per folder?
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?
Yes, I did, and I mentioned so in a previous post. I was unable to identify or correct the TBird problem, so I switched to LDA and sieve, which solved the issue for the most part.
See my follow on post replying to Timo for further information.
-- Stan
Hey Greg,
I picked up the right-size screwdrivers (P00, T6, T8) today. Still need to find a spudger, but I think I can use my fingernails until then.
How critical is antistatic for disassembly checking out the fan motors?
H
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.
Timo Sirainen put forth on 5/28/2010 10:55 AM:
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.
So it's the same caveat as with mbox_dirty_syncs = yes. If the caveats are the same, why do both settings exist, given that mbox_very_dirty_syncs=yes yields superior performance? Is there more potential danger with mbox_very_dirty_syncs? That was the impression I had, thus why I was using the "milder" setting.
-- Stan
On pe, 2010-05-28 at 16:00 -0500, Stan Hoeppner wrote:
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.
So it's the same caveat as with mbox_dirty_syncs = yes. If the caveats are the same, why do both settings exist, given that mbox_very_dirty_syncs=yes yields superior performance? Is there more potential danger with mbox_very_dirty_syncs? That was the impression I had, thus why I was using the "milder" setting.
With mbox_dirty_syncs it eventually notices the changes the next time the mailbox is SELECTed. But that's of course slow. The default behavior is similar to UW-IMAP's, that's the main reason the very dirty syncs isn't enabled by default.
participants (4)
-
Charles Marcus
-
Harlan Stenn
-
Stan Hoeppner
-
Timo Sirainen