[Dovecot] Maildir dirty syncs
http://dovecot.org/patches/1.1/maildir-dirty-syncs.diff
This patch adds a new maildir_very_dirty_syncs setting. If set to "yes", Dovecot assumes it's the only one changing the cur/ directory (so other MDAs can add mails to new/ without problems). This makes it possible to avoid rescanning the cur/ directory all the time looking for filenames. It also looks like (in stress testing) it still scans the cur/ directory unneededly in some situations, but it shouldn't be common. Maybe I'll look into it some day to see why.
I'd be interested in hearing how large performance benefits it gives, if any. If they're big I could consider adding it to v1.1.12. If they're pretty much irrelevant I probably won't even bother adding the code to v1.2. I guess you mainly see the performance benefits with large/huge mailboxes.
Le Wed, 04 Mar 2009 19:30:45 -0500 Timo Sirainen tss@iki.fi écrit:
http://dovecot.org/patches/1.1/maildir-dirty-syncs.diff
This patch adds a new maildir_very_dirty_syncs setting. If set to "yes", Dovecot assumes it's the only one changing the cur/ directory (so other MDAs can add mails to new/ without problems). This makes it possible to avoid rescanning the cur/ directory all the time looking for filenames. It also looks like (in stress testing) it still scans the cur/ directory unneededly in some situations, but it shouldn't be common. Maybe I'll look into it some day to see why.
Hi, does it means that if I only use dovecot to read the maidir (pop3 or imap), I can use this setting ?
Or does it mean that if there is always only one dovecot process reading the maildir, I can use this setting ?
What happens if I use this setting and I read the mailbox from 2 different webmail ?
-- Laurent Papier - 03 88 75 80 50 Admin. système - SdV Plurimedia - http://www.sdv.fr/
Am 05.03.2009, 12:21 Uhr, schrieb Edgar Fuß ef@math.uni-bonn.de:
Dovecot assumes it's the only one changing the cur/ directory Does this mean "there's no program that's not dovecot accesssing cur" or
"there's no other process than this dovecot accessing cur"? I.e., what about two dovecots on two servers with Maildirs on NFS?
It basically means "don't change cur/ contents behind Dovecot's back, else
it won't notice".
Two dovecots on two servers accessing *the same* Maildir/cur/ would be
just that.
-- Matthias Andree
On Mar 5, 2009, at 6:55 AM, Matthias Andree wrote:
Am 05.03.2009, 12:21 Uhr, schrieb Edgar Fuß ef@math.uni-bonn.de:
Dovecot assumes it's the only one changing the cur/ directory Does this mean "there's no program that's not dovecot accesssing
cur" or "there's no other process than this dovecot accessing cur"? I.e., what about two dovecots on two servers with Maildirs on NFS?It basically means "don't change cur/ contents behind Dovecot's
back, else it won't notice". Two dovecots on two servers accessing *the same* Maildir/cur/ would
be just that.
The important thing is if index files are updated. If index files are
also shared on NFS, it should work fine.
And actually in most cases Dovecot does notice if cur/ changes, it
just isn't guaranteed to notice anymore. If cur's mtime changes
unexpectedly, it's rescanned. But if it changes because Dovecot did
some changes, Dovecot doesn't rescan the cur/ anymore later to see if
someone else had done changes at the same time.
On Wed, 2009-03-04 at 19:30 -0500, Timo Sirainen wrote:
http://dovecot.org/patches/1.1/maildir-dirty-syncs.diff .. I'd be interested in hearing how large performance benefits it gives, if any.
Anyone?
I did a couple of small unrealistic tests with imaptest. With small mailboxes it shows no difference. With larger mailboxes it seemed to be about 25% faster:
N=old behavior, Y=dirty syncs
imaptest logout=0 secs=30 logout=0 msgs=1000 delete=10 expunge=10
Logi List Stat Sele Fetc Fet2 Stor Dele Expu Appe Logo
100% 50% 50% 100% 100% 100% 50% 10% 10% 100% 10%
30% 5%
N: 10 2122 2112 10 4146 5947 2045 334 411 2344
Y: 10 2911 2899 10 5761 8194 2758 444 578 3629
imaptest logout=0 secs=30 logout=0 msgs=10000 delete=10 expunge=10
Logi List Stat Sele Fetc Fet2 Stor Dele Expu Appe Logo
100% 50% 50% 100% 100% 100% 50% 10% 10% 100% 10%
30% 5%
N: 10 1553 1555 10 3129 4514 1548 245 336 3132 --> 2717 msgs in maildir
Y: 10 2157 2109 10 4189 6053 2035 310 441 4190 --> 3673 msgs in maildir
Although if the clients are disconnecting often, there's not much of an improvement:
imaptest box=lols logout=0 secs=30 logout=10 msgs=1000 delete=10 expunge=10
Logi List Stat Sele Fetc Fet2 Stor Dele Expu Appe Logo
100% 50% 50% 100% 100% 100% 50% 10% 10% 100% 10%
30% 5%
N: 502 2779 2837 502 5627 7996 2776 455 604 2411 1004
Y: 593 2909 2975 593 5892 8526 2895 467 559 2491 1186
participants (4)
-
Edgar Fuß
-
Laurent Papier
-
Matthias Andree
-
Timo Sirainen