[Dovecot] NFS performance and 1.1.3 - what can you (unofficially) get away with?
Jack Stewart
jstewart at caltech.edu
Wed Sep 10 20:58:37 EEST 2008
Hi,
Does anyone have experience with bending the NFS recommendations to get
better performance?
The question is has anyone, with Maildir and the INDEX= on NFS (i.e.
dovecot.index and dovecot.index.cache, set mail_nfs_index to no. If so,
was it better to turn maildir_copy_preserve_filename to on or did it
help to turn if off. The other question is did you play with turning off
atime updates or changing the acmin* values?
I know that the recommendation is do not do this. Fortunately Timo's
screams won't reach my ears for another ten hours. I'm just interested
if anyone has done this. You are most welcome to reply offline.
I figure that the worst that can happen is that the dovecot.index.cache
file will become corrupt, and dovecot will then rebuild it. As long as
this doesn't happen all the time, it should not be a big deal. I'm
guessing that this is less likely maildir_copy_preserve_filename turned
on. My old (courier) servers is that I was able to get away with
disabling atime updates and bumping up acmin* but then there was no
central index to check.
I admit that this is a nutty way to go since part of the whole point of
1.1.X is its NFS settings. Yet this is a place with some pretty nutty
users. (i.e. 2+GB inboxes, 100K messages, one/minute connections, ...)
---Jack
P.S. As a total aside people migrating from 1.0.X to 1.1.3 may wish to
have to use a different INDEX directory in 1.1.3 than the one you used
in 1.0.7. Doing this got rid of my index.cache and transaction log error
messages. This may be why testing isn't showing anything.
P.P.S. I've tried imapproxy for my webmail but it doesn't seem to have
made much of a difference on the INDEX I/O.
More information about the dovecot
mailing list