Message-ID: <4C5B58E0.9060902@catalyst.net.nz>
Date: Fri, 06 Aug 2010 12:35:44 +1200
From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Advice configuring ServeRAID 8k for performance
References: <op.vgy9k5ov5ru9c3@kent60.office.vivox.com>
	<4C5B4A0C.5080508@catalyst.net.nz>
	<201008051658.13399@hal.medialogik.com>
	<4C5B57F6.8070104@catalyst.net.nz>
In-Reply-To: <4C5B57F6.8070104@catalyst.net.nz>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

On 06/08/10 12:31, Mark Kirkwood wrote:
> On 06/08/10 11:58, Alan Hodgson wrote:
>> On Thursday, August 05, 2010, Mark 
>> Kirkwood<mark.kirkwood@catalyst.net.nz>
>> wrote:
>>> Normally I'd agree with the others and recommend RAID10 - but you say
>>> you have an OLAP workload - if it is *heavily* read biased you may get
>>> better performance with RAID5 (more effective disks to read from).
>>> Having said that, your sequential read performance right now is pretty
>>> low (151 MB/s  - should be double this), which may point to an issue
>>> with this controller. Unfortunately this *may* be important for an OLAP
>>> workload (seq scans of big tables).
>> Probably a low (default) readahead limitation. ext3 doesn't help but 
>> it can
>> usually get up over 400MB/sec. Doubt it's the controller.
>>
>
> Yeah - good suggestion, so cranking up readahead (man blockdev) and 
> retesting is recommended.
>
>

... sorry, it just occurred to wonder about the stripe or chunk size 
used in the array, as making this too small can also severely hamper 
sequential performance.

Cheers

Mark