/usr/share/doc/cyrus-doc/html/install-perf.html is in cyrus-doc 2.5.10-3.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org" />
<meta http-equiv="Content-type" content="text/html;charset=UTF-8" />
<title>Performance Notes</title>
</head>
<body>
<h1>Performance Notes</h1>
Cyrus presents various performance issues for you to consider. If you never expect to have
more than 100 simultaneous users, chances are any hardware you have
will be fine. If you plan on having thousands or more users, please
be sure to review this section.
<p>If your configuration directory is not <tt>/var/imap</tt>,
adjust accordingly.</p>
<ul>
<li><tt><b>/var/imap/proc</b></tt> - After a successful login, the
<tt>imapd</tt> creates a file in <tt>var/imap/proc</tt> that is its unix
process id. It also contains the name of any <tt>SELECT</tt>ed
mailbox. The file is deleted when the user logs out.
<p>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' <tt>tmpfs</tt>). If you use a <tt>tmpfs</tt> type
filesystem, make sure that you have sufficient memory/swap to do
this.</p>
<p>Some people don't care about this information and just <tt>#ifdef</tt>
out the code. We probably should add a <tt>configure</tt> option to
do this.</p>
</li>
<li><tt><b>/var/imap/mailboxes.db</b></tt> - The mailboxes list is often
the ultimate source of contention between <tt>imapd</tt> 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, as opposed to the default, Berkeley DB
(use <tt>--with-mboxlist-db=skiplist</tt>).
<p>Mika Iisakkila (<i>mika.iisakkila@pingrid.fi</i>) writes: Nevertheless,
you can also tweak the Berkeley backend if you want to or have to stick
with it. Cyrus doesn't do anything to increase the BDB cache size, and the
default (256 kB) is way too small for any reasonably large site. With some
50000 mailboxes and random operations, I found the hit rate for the default
BDB cache to be 70-80%. After growing the cache size to 2M, the hit rate
approached 99% and disk traffic was greatly reduced since most of the
operations are reads anyway. Therefore processes could complete their work
and release their locks much more quickly, and the dreaded "DBERROR: xxx
lockers" messages stayed at a comfortable level. You can modify the source
(<tt>/lib/cyrusdb_db3.c</tt>, the setting is commented out) or you can put
a <tt>DB_CONFIG</tt> file under <tt>/var/imap/db</tt> with the appropriate
setting. Read more about this in the Berkeley docs before trying it - typos
and incorrect settings can wreak havoc.</p></li>
<li><tt><b>/var/imap/deliverdb</b></tt> - 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.
<p>We run with it enabled and it doesn't significantly impact our
performance.</p>
</li>
<li><tt><b>/var/spool/mqueue</b></tt> - 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.</li>
<li>Unused SASL mechanisms - If you just build the SASL library and
copy all the mechanisms into <tt>/usr/lib/sasl2</tt>, the <tt>imapd</tt>
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
<tt>usr/lib/sasl2</tt> and if you don't plan on using those mechanisms,
don't leave them there.</li>
<li>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 <tt>tcpListenDrop</tt> (from <tt>netstat
-sP tcp</tt>).</li>
<li>Database recovery. If restarting the server takes a long
time due to the <tt>cyrusdb</tt> 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
<tt>cyrusdb</tt> event in <tt>/etc/cyrus.conf</tt>. We run
checkpoints every 5 minutes; the current suggested install interval
is 30 minutes.</li>
<li>Some filesystems support the <tt>noatime</tt> mount option. The
server does not use the atime information so you can go ahead and
enable this feature.</li>
<li>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 <tt>etc/syslog.conf</tt> with a "-", e.g., "<code>/var/log/maillog</code>"
becomes "<tt>-/var/log/maillog</tt>", 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.</li>
</ul>
<p>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 <tt>imapd</tt> 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.</p>
<p>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.</p>
<p>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.</p>
<hr />
last modified: $Date: 2010/01/06 17:01:29 $
</body>
</html>
|