Message-ID: <44CA1C81.8060703@eclinic.com.au>
Date: Sat, 29 Jul 2006 00:17:37 +1000
From: Leigh Dyer <leigh@eclinic.com.au>
User-Agent: Thunderbird 1.5.0.4 (X11/20060615)
MIME-Version: 1.0
To: pgsql-performance@postgresql.org,
	Mikael.Carneholm@WirelessCar.com
Subject: Re: Performance with 2 AMD/Opteron 2.6Ghz and 8gig
References: <7F10D26ECFA1FB458B89C5B4B0D72C2B4E4D8C@sesrv12.wirelesscar.com>
In-Reply-To: <7F10D26ECFA1FB458B89C5B4B0D72C2B4E4D8C@sesrv12.wirelesscar.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Mikael Carneholm wrote:
> I would be interested in what numbers you would get out of bonnie++
> (http://www.coker.com.au/bonnie++) and BenchmarkSQL
> (http://sourceforge.net/projects/benchmarksql) on that hardware, for
> comparison with our DL385 (2xOpteron 280, 16Gb ram) and MSA1500. If you
> need help building benchmarksql, I can assist you with that.
> 
> Actually, I would be interested if everyone who's reading this that has
> a similar machine (2 cpu, dual core opteron) with different storage
> systems could send me their bonnie + benchmarksql results! 
> 

Here's the bonnie++ results from our Sun Fire V40z (2x Opteron 250, 4GB 
RAM) with 6 15krpm 73GB drives connected to an LSI MegaRAID 320-2X 
controller with 512MB cache. It's running Linux, and I'm using what 
seems to be a fairly typical 6-drive setup: 2 drives in RAID-1 for OS 
and WAL, and 4 drives in RAID-10 for data. This is from the 4-drive 
RAID-10 array:

Version  1.03       ------Sequential Output------ --Sequential Input- 
--Random-
                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- 
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP 
/sec %CP
gaz              8G 56692  88 73061  12 33048   6 44994  64 132571  14 
474.0   0
                     ------Sequential Create------ --------Random 
Create--------
                     -Create-- --Read--- -Delete-- -Create-- --Read--- 
-Delete--
               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP 
/sec %CP
                  16 19448  88 +++++ +++ 18611  72 19952  90 +++++ +++ 
15167  65

This system is actually in production currently, and while it's a rather 
quiet time at the moment, it still wasn't _entirely_ inactive when those 
numbers were run, so the real performance is probably a little higher. 
I'll see if I can run some BenchmarkSQL numbers as well.

Thanks
Leigh

> /Mikael
>  
> 
> -----Original Message-----
> From: pgsql-performance-owner@postgresql.org
> [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Luke
> Lonergan
> Sent: den 28 juli 2006 08:55
> To: Kjell Tore Fossbakk; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Performance with 2 AMD/Opteron 2.6Ghz and 8gig
> 
> Kjell,
> 
>> I got 4 150GIG SCSI disks in a Smart Array 5i 1+0 RAID.
> 
> The Smart Array 5i is a terrible performer on Linux.  I would be
> surprised if you exceed the performance of a single hard drive with this
> controller when doing I/O from disk.  Since your database working set is
> larger than memory on the machine, I would recommend you use a simple
> non-RAID U320 SCSI controller, like those from LSI Logic (which HP
> resells) and implement Linux software RAID.  You should see a nearly 10x
> increase in performance as compared to the SmartArray 5i.
> 
> If you have a good relationship with HP, please ask them for some
> documentation of RAID performance on Linux with the SmartArray 5i.  I
> predict they will tell you what they've told me and others: "the 5i is
> only useful for booting the OS".  Alternately they could say: "we have
> world record performance with our RAID controllers", in which case you
> should ask them if that was with the 5i on Linux or whether it was the
> 6-series on Windows.
> 
> - Luke
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
> 
>                http://archives.postgresql.org
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>