Re: RAID 0 not as fast as expected

["Luke Lonergan" <llonergan(at)greenplum(dot)com>]

Greg, Josh,

Something I found out while doing this - lvm (and lvm2) slows the block
stream down dramatically.  At first I was using it for convenience sake to
implement partitions on top of the md devices, but I found I was stuck at
about 700 MB/s.  Removing lvm2 from the picture allowed me to get within
chucking distance of 2GB/s.

When we first started working with Solaris ZFS, we were getting about
400-600 MB/s, and after working with the Solaris Engineering team we now get
rates approaching 2GB/s.  The updates needed to Solaris are part of the
Solaris 10 U3 available in October (and already in Solaris Express, aka
Solaris 11).

- Luke   


On 9/15/06 5:43 AM, "Spiegelberg, Greg" <gspiegelberg(at)cranel(dot)com> wrote:

> That's an all PCI-X box which makes sense.  There are 6 SATA controllers
> in that little beastie also.  You can always count on Sun to provide
> over engineered boxes.
> 
>  
> 
>> -----Original Message-----
>> From: pgsql-performance-owner(at)postgresql(dot)org
>> [mailto:pgsql-performance-owner(at)postgresql(dot)org] On Behalf Of
>> Joshua D. Drake
>> Sent: Friday, September 15, 2006 12:01 AM
>> To: Luke Lonergan
>> Cc: Craig A. James; pgsql-performance(at)postgresql(dot)org
>> Subject: Re: [PERFORM] RAID 0 not as fast as expected
>> 
>> Luke Lonergan wrote:
>>> Josh,
>>> 
>>> On 9/14/06 8:47 PM, "Joshua D. Drake" <jd(at)commandprompt(dot)com> wrote:
>>> 
>>>>> I've obtained 1,950 MB/s using Linux software RAID on SATA drives.
>>>> With what? :)
>>> 
>>> Sun X4500 (aka Thumper) running stock RedHat 4.3 (actually
>> CentOS 4.3) 
>>> with XFS and the linux md driver without lvm.  Here is a
>> summary of the results:
>>> 
>> 
>> 
>> Good god!
>> 
>>>      
>>>  Read Test     
>>>  RAID Level Max Readahead (KB) RAID Chunksize Max Readahead
>> on Disks 
>>> (KB) Max Time (s)  Read Bandwidth (MB/s)  0 65536 64 256 16.689
>>> 1,917.43  0 4096 64 256 21.269  1,504.54  0 65536 256 256 17.967
>>> 1,781.04  0 2816 256 256 18.835  1,698.96  0 65536 1024 256 18.538
>>> 1,726.18  0 65536 64 512 18.295  1,749.11  0 65536 64 256 18.931
>>> 1,690.35  0 65536 64 256 18.873  1,695.54  0 64768 64 256 18.545
>>> 1,725.53  0 131172 64 256 18.548  1,725.25  0 131172 64
>> 65536 19.046  
>>> 1,680.14  0 131172 64 524288 18.125  1,765.52  0 131172 64 1048576
>>> 18.701  1,711.14
>>>  5 2560 64 256 39.933  801.34
>>>  5 16777216 64 256 37.76  847.46
>>>  5 524288 64 256 53.497  598.16
>>>  5 65536 32 256 38.472  831.77
>>>  5 65536 32 256 38.004  842.02
>>>  5 65536 32 256 37.884  844.68
>>>  5 2560 16 256 41.39  773.13
>>>  5 65536 16 256 48.902  654.37
>>>  10 65536 64 256 83.256  384.36
>>>  1+0 65536 64 256 19.394  1,649.99
>>>  1+0 65536 64 256 19.047  1,680.05
>>>  1+0 65536 64 256 19.195  1,667.10
>>>  1+0 65536 64 256 18.806  1,701.58
>>>  1+0 65536 64 256 18.848  1,697.79
>>>  1+0 65536 64 256 18.371  1,741.88
>>>  1+0 65536 64 256 21.446  1,492.12
>>>  1+0 65536 64 256 20.254  1,579.93
>>> 
>>> 
>> 
>> 
>> -- 
>> 
>>     === The PostgreSQL Company: Command Prompt, Inc. ===
>> Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
>>     Providing the most comprehensive  PostgreSQL solutions since 1997
>>               http://www.commandprompt.com/
>> 
>> 
>> 
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 2: Don't 'kill -9' the postmaster
>> 
>