Performance Notes

If your configuration directory is not /var/imap, adjust accordingly.

• /var/imap/proc - After a successful login, the imapd creates a file in var/imap/proc that is its unix process id. It also contains the name of any SELECTed mailbox. The file is deleted when the user logs out.

  Given the potential load, this is a good candidate to move elsewhere. This can be done by symlink'ing the directory to another partition. We symlink it to a directory on a memory/virtual memory filesystem (specifically Solaris' tmpfs). If you use a tmpfs type filesystem, make sure that you have sufficient memory/swap to do this.

  Some people don't care about this information and just #ifdef out the code. We probably should add a configure option to do this.

• /var/imap/mailboxes.db - The mailboxes list is often the ultimate source of contention between imapd processes, especially if clients are inefficient about their use of the LIST command. For this reason it is often better to use the skiplist backend which is optimized for enumeration of the database, which is currently the default.
• /var/imap/deliverdb - Unless you disable duplicate delivery suppression, each time a mail message is delivered it needs to lock the database and check to see if the message-id has been seen already. If you require really high throughput delivery, you may want to disable this feature.

  We run with it enabled and it doesn't significantly impact our performance.

• /var/spool/mqueue - Sendmail can be pretty harsh on the spool partition. Having this on a separate disk is usually a good idea. Consider using LMTP and delivering from a separate machine.
• Unused SASL mechanisms - If you just build the SASL library and copy all the mechanisms into /usr/lib/sasl2, the imapd will try to use them and allocate some amount of memory for each. In general, the operating system will swap out those pages but you may be allocating more swap space than you need. So look in usr/lib/sasl2 and if you don't plan on using those mechanisms, don't leave them there.
• You may want to increase the listen queue value when starting up the master process. For example, you may want to do this if you see the listen queue drop counter increasing quickly. Under Solaris, look at the variable tcpListenDrop (from netstat -sP tcp).
• Database recovery. If restarting the server takes a long time due to the cyrusdb database recovery procedure (this is usually true if you have a large number of deliveries) you should look into shortening the interval between checkpoints, controlled by the cyrusdb event in /etc/cyrus.conf. We run checkpoints every 5 minutes; the current suggested install interval is 30 minutes.
• Some filesystems support the noatime mount option. The server does not use the atime information so you can go ahead and enable this feature.
• Depending on your syslog configuration and usage volume, Cyrus may generate thousands of syslog messages. On Linux, syslog performance can be greatly improved by disabling synchronous logging (disabling fsync() after each message). Prepending filenames in etc/syslog.conf with a "-", e.g., "/var/log/maillog" becomes "-/var/log/maillog", disables syslog's fsync() call after each log message. If you log many messages those fsync()s will kill your I/O throughput. Note that if you do not need the detail provided by the LOG_DEBUG level, then not logging these messages can significantly reduces the number of log entries that Cyrus makes.

In general, there's no magic bullet for performance. It depends on your hardware, your operating system, and how your users use the system. In general, an imapd process takes up anywhere from 256 Kbytes of memory to 512 Kbytes when it is first fired up. CPU has not been a big deal, but it may become more important as the IMAP sessions are encrypted and now that searching may be more frequent. Disk I/O is probably the most important and having a hardware RAID subsystem with a decent amount of write-back cache would be a good thing.

Again, if you are talking about less than 100 interactive users it is likely that any relatively modern hardware can support it. If you are talking about having more than 1000 interactive users, you should know how to predict your utilization, go overboard on hardware, be willing to suffer growing pains, or be able to hire someone that can help.

There are a number of good performance tuning articles out for Solaris by Adrian Cockcroft. Go to your favorite search engine and look for his name.