Re: Load spikes when new email arrives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 24 Jan 2013, francis picabia wrote:

> In another email discussion on the Redhat mailing list, I've confirmed we
> have
> an issue with partition alignment.  This is getting to be quite the mess
> out there.  I saw one posting where it is speculated there are thousands of
> poorly set up disk partitions for their RAID stripe size.  fdisk and
> OS installers were late getting updated for the new TB disks
> and SSD disks as well.  Partition alignment might account
> for 5 to 30% of a performance hit.

Yeah, I read about partition alignment the last time I built a new Cyrus 
server.  I don't remember how it came to my attention, but it was wrong on 
all of my servers too.  The latest stable release of Debian Linux seems to 
do the right thing during installation, but previous versions did not.

I followed the recommendations that I found and set the starting sector to 
2048 for my partition (2048 * 512bytes = 1MB):

root@cyrus-be1:~# fdisk -lu /dev/sda

Disk /dev/sda: 536.9 GB, 536870912000 bytes
214 heads, 31 sectors/track, 158060 cylinders, total 1048576000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x88aa51ee

    Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048  1048575999   524286976   83  Linux

I don't know how much of a performance difference it would actually make, 
but I'm trying to squeeze all I can out of it!

> I've checked and my cyrus lmtpd process count
> never exceeds 11 under work load.
> await jumps up to 150-195 at worst.
>
> If I'm already at IO saturation, I can't see how a higher lmtpd limit
> would help.

I was going to suggest setting a LOWER lmtpd limit.  :)

It sounds like you have already done that (reading the rest of this email 
thread).

> My goal is to keep the system load reasonable so it is responsive for
> mailbox access by the end users.  Right now we get nagios alerts
> about 6 times a day for excessive load.  If I can move the mail
> queue workload into a hill instead of a sharp peak on the cacti
> load graph, it would be good.  There are minutes around the peaks
> where the queue is emptied and we have only 5 messages
> inbound per minute.

Hmmm, what options are there that don't involve rebuilding the disk...

Definitely check that you have Write-Back caching enabled on the PERC.

I don't know if remounting the filesystem as ext4 would help, but that's 
worth a shot.

Are you mounting the filesystem with the "noatime" option?  There is no 
need to track atime on a Cyrus mailstore and those extra writes can add 
up.  Here are my mount options:

LABEL=be1data1  /var/spool/cyrus/mail/data1     ext4    rw,auto,data=ordered,noatime   0       2

Perhaps there are some tweaks on the Postfix side that will put less 
strain on Cyrus.  I don't know much about Postfix though.

> In hind sight, I agree RAID 10 should have been implemented.
> At the time, four years ago, getting lots of space was the
> priority as space needs always grow.  We've never seen load
> issues until this month, and it seems to coincide with a
> general increase of all email volume and traffic.  Our primary
> MX is also getting hit more than normal.

Well, if none of the easy stuff helps enough, then maybe you'll get to 
build a new Cyrus filesystem from scratch!  :)

 	Andy
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


[Index of Archives]     [Cyrus SASL]     [Squirrel Mail]     [Asterisk PBX]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux