On Tue, 6 Jan 2015, Piers Rowan <piers.rowan@recruitonline.com.au> wrote:
On 06/01/15 10:11, Russell Coker wrote:
If the problem is indexing on the IMAP server then you could try configuring the IMAP server to use different indexing or to use a different IMAP server program. Dovecot seems to have some reasonable options for indexing that don't waste much CPU time.
This also depends on the nature of your back end storage - like NFS for example when you can get time out's for read lock.
If you want decent performance with IMAP then just don't use NFS. The write pattern of mail stores is a poor match for the way NFS works and the large number of files doesn't work too well for read caching.
The issue isn't so much the dovecot can be configured to do x with y resources it has to do with the fact that things are generally in production and have web mail, AV, mailman, SMTP, procmail, SA, etc all working together in real time on a single node. Fixing/messing with one function of the server can impact the others.
If you have a running mail server it's not too difficult to change the process that serves POP/IMAP without changing the rest. You can even have 2 programs serving POP/IMAP on different ports or IP addresses until you are happy that the new one does everything correctly.
My recommendations are don't have endless email archives (none of us are really that important) and expect to wait when you start moving relatively large chunks of plain text files around that are split are arbitrary lines aka mail spool files.
Apart from the recent versions of Kmail (which have some mandatory indexing features which seem useless and hurt performance) I've never had such problems. Use an SSD for your local mail store and you shouldn't have any problems. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/