pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Greg Smith <gsmith@gregsmith.com>
To: pgsql-performance@postgresql.org
Subject: Re: Bad iostat numbers
Date: Mon, 4 Dec 2006 23:10:00 -0500 (EST)
Message-ID: <Pine.GSO.4.64.0612041946120.9323@westnet.com> (raw)
In-Reply-To: <33c6269f0612032317t9f0bc77n3ff791a5cd88fc80@mail.gmail.com>
References: <PEEPKDFEHHEMKBBFPOOKKEHCDKAA.carlos.reimer@opendb.com.br>
	<Pine.GSO.4.64.0612032336250.19679@westnet.com>
	<33c6269f0612032317t9f0bc77n3ff791a5cd88fc80@mail.gmail.com>

On Mon, 4 Dec 2006, Alex Turner wrote:

> People recommend LSI MegaRAID controllers on here regularly, but I have 
> found that they do not work that well.  I have bonnie++ numbers that 
> show the controller is not performing anywhere near the disk's 
> saturation level in a simple RAID 1 on RedHat Linux EL4 on two seperate 
> machines provided by two different hosting companies. 
> http://www.infoconinc.com/test/bonnie++.html

I don't know what's going on with your www-september-06 machine, but the 
other two are giving 32-40MB/s writes and 53-68MB/s reads.  For a RAID-1 
volume, these aren't awful numbers, but I agree they're not great.

My results are no better.  For your comparison, here's a snippet of 
bonnie++ results from one of my servers: RHEL 4, P4 3GHz, MegaRAID 
firmware 1L37, write-thru cache setup, RAID 1; I think the drives are 10K 
RPM Seagate Cheetahs.  This is from the end of the drive where performance 
is the worst (I partitioned the important stuff at the beginning where 
it's fastest and don't have enough free space to run bonnie there):

------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
20708  50 21473   9  9603   3 34419  72 55799   7 467.1   1

21Mb/s writes, 56MB/s reads.  Not too different from yours (especially if 
your results were from the beginning of the disk), and certainly nothing 
special.  I might be able to tune the write performance higher if I cared; 
the battery backed cache sits unused and everything is tuned for paranoia 
rather than performance.  On this machine it doesn't matter.

The thing is, even though it's rarely the top performing card even when 
setup perfectly, the LSI SCSI Megaraid just works.  The driver is stable, 
caching behavior is well defined, it's a pleasure to administer.  I'm 
never concerned that it's lying to me or doing anything to put data at 
risk.  The command-line tools for Linux work perfectly, let me look at or 
control whatever I want, and it was straighforward for me to make my own 
customized monitoring script using them.

> LSI MegaRAID has proved to be a bit of a disapointment.  I have seen 
> better numbers from the HP SmartArray 6i, and from 3ware cards with 
> 7200RPM SATA drives.

Whereas although I use 7200RPM SATA drives, I always try to keep an eye on 
them because I never really trust them.  The performance list archives 
here also have plenty of comments about people having issues with the 
SmartArray controllers; search the archives for "cciss" and you'll see 
what I'm talking about.

The Megaraid controller is very boring.  That's why I like it.  As a Linux 
distribution, RedHat has similar characteristics.  If I were going for a 
performance setup, I'd dump that, too, for something sexier with a newish 
kernel.  It all depends on which side of the performance/stability 
tradeoff you're aiming at.

On Mon, 4 Dec 2006, Scott Marlowe wrote:
> Does RHEL4 have the megaraid 2 driver?

This is from the moderately current RHEL4 installation I had results from 
above.  Redhat has probably done a kernel rev since I last updated back in 
September, haven't needed or wanted to reboot since then:

megaraid cmm: 2.20.2.6 (Release Date: Mon Mar 7 00:01:03 EST 2005)
megaraid: 2.20.4.6-rh2 (Release Date: Wed Jun 28 12:27:22 EST 2006)

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD



view thread (22+ messages)  latest in thread

Message-ID: <Pine.GSO.4.64.0612041946120.9323@westnet.com>
Permalink:  ../Pine.GSO.4.64.0612041946120.9323@westnet.com/
Also on:    postgresql.org/message-id/Pine.GSO.4.64.0612041946120.9323@westnet.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: gsmith@gregsmith.com
  Subject: Re: Bad iostat numbers
  In-Reply-To: <Pine.GSO.4.64.0612041946120.9323@westnet.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox