<br><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 1:55 PM, Andrew Morgan <span dir="ltr"><<a href="mailto:morgan@orst.edu" target="_blank">morgan@orst.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Wed, 23 Jan 2013, francis picabia wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here are more stats. Do these look average for performance?<br>
It is difficult to understand why the system was working with few<br>
load spikes before.<br>
<br>
A mailman mailing list sends 10kbyte message to 4000<br>
users having accounts on this cyrus system. If I<br>
grep "Delivered" in the maillog by the minute I can<br>
see how fast the messages are stored.<br>
<br>
e.g.:<br>
# grep Delivered /var/log/maillog | grep 'Jan 23 10:37' | wc -l<br>
696<br>
<br>
That is the best. This peak event pushed the load to 14<br>
for 12 minutes, where it averages 604 messages<br>
delivered to cyrus mailboxes per minute. Is that<br>
reasonable for maximum delivery rate?<br>
<br>
I've also backed out the change (yesterday) to<br>
/sys/block/sda/queue/nr_<u></u>requests<br>
I think it was pushing the load higher and there is no advantage<br>
in my hardware (SAS with Perc 5/i Raid 5 over 4 disk)<br>
to run with a low value for nr_requests.<br>
</blockquote>
<br></div></div>
You can certainly achieve higher delivery rates, but that all depends on your underlying hardware and how you have partitioned your system.<br>
<br>
Why don't you start running "iostat -x 5" on the system? Leave this running to give you an idea of the baseline behavior and then look at it during periods of high load. I suspect you will see that your svctm and %util will go up dramatically when a large number of messages are being delivered. But, let's not make decisions based on assumptions! :)<br>
<br>
On my Cyrus Murder frontends (3 of them), I have limited LMTP connections to 25 in cyrus.conf:<br>
<br>
lmtp cmd="/usr/local/cyrus/bin/<u></u>lmtpproxyd" listen="lmtp" proto="tcp4" prefork=0 maxchild=25<br>
<br>
This prevents our mail relays (Postfix) from opening too many simultaneous LMTP connections, which can cause too much I/O contention. Take a look during your periods of high load to see how many lmtpd processes are running. You may want to limit the number.<br>
<br>
Andy<br>
</blockquote></div><br>Thanks for the response. I have been checking my iostat whenever there is<br>a number of messages in the active queue.<br><br>Here is a sample snapshot from a script I run (ignoring the first<br>iostat output of averages):<br>
<br>Active in queue: 193<br> 12:47:01 up 5 days, 5:23, 6 users, load average: 14.11, 9.22, 4.67<br><br>Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util<br>sda5 3.25 281.00 19.75 129.50 654.00 3384.00 27.06 5.53 36.24 6.69 99.80<br>
<br>svctm is about the same as when not under load and it went above 7 only once.<br>Then there is this comment about the validity of tracking svctm:<br><a href="http://www.xaprb.com/blog/2010/09/06/beware-of-svctm-in-linuxs-iostat/">http://www.xaprb.com/blog/2010/09/06/beware-of-svctm-in-linuxs-iostat/</a><br>
<br>%util is often reaching close to %100 when there is a queue to process.<br><br>sda5 is where the cyrus mail/imap lives. Our account names all begin with<br>numbers, so almost all mail accounts are under the q folder.<br>
<br>I'll check the lmtp process numbers as well. I've put in some in_flow_delay on the<br>postfix side so it might keep the load from peaking as sharply.<br><br><br>