1

We're having some major issues with our mail server, normally after a reboot (but not always) where disk io will shoot up from an average 50-100mbps, to 200-300 mbps.

I've narrowed it down to dovecot, killing dovecot brings disk usage to normal immediately. I would say that maybe it's just dovecot processing a backlog after an outage, as we did have an outage for a few hours yesterday, but it settled yesterday evening, then ramped back up again today.

Using atop I've found specific imap accounts that are causing the issues. I've contacted the clients, and found that all the highest io clients have been deleting large quantities of email from their inboxes.

Obviously can't stop them from doing that, but the increased disk io causes a lot of io wait and services stop responding, so we need a way to reduce dovecot's io footprint. I know you can nice something to reduce it's cpu priority, is there something similar for disk priority?

Our server management team says it's as good as it's going to get, and we need to allocate more resources to dovecot, but I'd prefer to rule out the possibility of bad configuration before we throw another server at it, only to have the issues follow us. 300mbps from a few people deleting their email sounds a bit excessive IMHO.

Below is an output of our dovecot configuration from dovecot -n. Any assistance anyone can provide would be greatly appreciated.

You'll see I've already tried disabling fsync as per this article: http://wiki.dovecot.org/PerformanceTuning. Haven't noticed any considerable improvement. Any suggestions anyone could provide would be greatly appreciated.

Edit: We have one file per user, stored in /var/spool/mail, so I'm guessing it's mbox format.

# 1.0.7: /etc/dovecot.conf
log_timestamp: %Y-%m-%d %H:%M:%S 
protocols: imap imaps pop3
login_dir: /var/run/dovecot/login
login_executable(default): /usr/libexec/dovecot/imap-login
login_executable(imap): /usr/libexec/dovecot/imap-login
login_executable(pop3): /usr/libexec/dovecot/pop3-login
verbose_proctitle: yes
mail_privileged_group: mail
fsync_disable: yes
mail_executable(default): /usr/libexec/dovecot/imap
mail_executable(imap): /usr/libexec/dovecot/imap
mail_executable(pop3): /usr/libexec/dovecot/pop3
mail_plugin_dir(default): /usr/lib64/dovecot/imap
mail_plugin_dir(imap): /usr/lib64/dovecot/imap
mail_plugin_dir(pop3): /usr/lib64/dovecot/pop3
auth default:
  mechanisms: plain login
  passdb:
    driver: pam
  userdb:
    driver: passwd
  socket:
    type: listen
    client:
      path: /var/spool/postfix/private/auth
      mode: 432
      user: postfix
      group: postfix
    master:
      path: /var/run/dovecot/auth-master
      mode: 384
      user: root
Improve this question

1 Answer 1

Reset to default
1

You don't say what mailbox format you're using.

Dovecot is nice because it supports the standard mbox format. It's simple to set up this way.

The problem is, the standard mbox format is just one big file; an operation on a message in the middle of the file can cause a rewrite of the entire second half.

Dovecot also supports the Maildir format. This stores messages one per file. This can have issues too - but when you've got users with huge mail quotas it's likely the lesser evil.

There may be dovecot plugins for other formats but from what I can tell there aren't any other directly supported mailbox formats.

Improve this answer
4
  • I didn't really know which is which, but based on your description, we have one file per email user, in the /var/spool/mail directory, so I'm guessing mbox.
    – Tom McQuarrie
    Aug 14, 2012 at 4:39
  • Yes that's mbox. I would also agree that using Maildir is much more preferential than mbox. wiki.dovecot.org/Migration/MailFormat for information on migrating.
    – Garrett
    Aug 14, 2012 at 20:59
  • Doing some more research, seems like deletes are one of the more disk-intensive operations on mbox files, as if the delete is near the top of the file the entire remaining file needs to be re-written to disk. Seems like this could be the culprit, so moving to maildir could provide significant increases in this area. Currently assessing the move with our server guys.
    – Tom McQuarrie
    Aug 15, 2012 at 5:49
  • Yes, that's what i was getting at when i wrote "an operation on a message in the middle of the file can cause a rewrite of the entire second half." Upon further thought, it might be an entire rewrite no matter what. that would be safer. I imagine dovecot caches its updates but as you have learned it's still ugly. really, anything that changes the mbox file in any way causes a rewrite. The first time you read a message with dovecot, it will rewrite because it adds a few of its own headers. See wiki.dovecot.org/MboxProblems for more.
    – Dan Pritts
    Aug 15, 2012 at 15:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .