[Dovecot] Poor pop3 over nfs performance
Hi,
About a week ago I upgraded our reasonably heavily loaded mail servers from a pretty recent courier version to dovecot-1.1rc10. 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. 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. I've also attached graphs of the relative network usage - as you can see, dovecot is using up to 100mbps whereas courier is using less than 10mbps; I believe this is due to the read. I initially assumed this high read load was due to courier building up its index files, but this has now been happening for about a week with little variation.
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 mail_nfs_storage: yes mail_nfs_index: yes lock_method: dotlock maildir_copy_preserve_filename: yes
Thanks,
Mark
Sorr I can't give you an answer for your problem, but...
On 6/30/2008 12:05 PM, Mark Zealey wrote:
About a week ago I upgraded our reasonably heavily loaded mail servers from a pretty recent courier version to dovecot-1.1rc1o.
1.1.1 was released on 6/22, so you're a bit behind the curve... its normally recommended to upgrade to a release version before reporting problems...
relevant config options are:
Output of dovecot -n is preferred to selective snips from dovecot.conf...
Also, dovecot is primarily an IMAP server, but someone else will have to tell you if the POP performance you are experiencing is normal or not...
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?
participants (3)
-
Charles Marcus
-
Mark Zealey
-
Timo Sirainen