On Mon, 2008-06-30 at 17:05 +0100, Mark Zealey wrote:
Hi,
About a week ago I upgraded our reasonably heavily loaded mail servers from a pretty recent courier version to dovecot-1.1rc10.
rc11 had this fix which may be relevant:
- dovecot-uidlist is now recreated if it results in file shrinking
over 25%.IMAP performance on dovecot is amazing, however POP3 performance is worse than courier :-( I have uploaded some munin graphs taken today to http://linweb.atlas.pipex.net/dovecot/; the dovecot server is handling about 2000 pop logins/sec and 300 imap sessions (but these are negligible in terms of nfs ops). The courier server is handling a similar number of pop logins/sec but no imap (slightly less traffic overall but a similar number of logins). As you can see, dovecot seems to issue an awful lot more read requests than courier.
Dovecot's POP3 performance isn't that great, but it shouldn't be (much) worse than Courier's since they both use a nearly identical dovecot-uidlist/courierpop3dsizes files.
The big spike at 10am is where I tried setting the :INDEX=MEMORY flag on dovecot as I assumed that's what courier is doing.
With v1.1 INDEX=MEMORY shouldn't matter that much anymore, since it should cache the virtual message size to dovecot-uidlist.
Do you have ,W=<size> in maildir filenames? Apparently not?
Do you have W=<size> added to dovecot-uidlist?
Are your POP3 users download + delete or do they leave mail on the server?
The servers are both centos 5.0 (perhaps 5.1 actually, but with the latest centosplus kernel which fixes the nfs lookup bug in the standard kernels); and are not running any other nfs programs. The NFS server is a high performance NAS unit - no issues there. We're only using Maildirs; relevant config options are:
mmap_disable: yes dotlock_use_excl: no
You should be able to use dotlock_use_excl=yes.
mail_nfs_storage: yes mail_nfs_index: yes lock_method: dotlock
dotlock is the slowest locking method. Did you try how well fcntl would have worked?