Message-ID: <445651F1.9070307@jobflash.com>
Date: Mon, 01 May 2006 11:22:41 -0700
From: Tom Arthurs <tarthurs@jobflash.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: erik.myllymaki@aviawest.com
Cc: Mark Lewis <mark.lewis@mir3.com>, Vivek Khera <vivek@khera.org>,
	Pgsql performance <pgsql-performance@postgresql.org>
Subject: Re: hardare config question
References: <445236D5.5060509@aviawest.com>	
	<3DFCE70E-E4BB-40AB-B27F-99E90E8159CA@khera.org>
	<1146246441.15712.41.camel@archimedes>
	<44564C3F.2040609@aviawest.com>
In-Reply-To: <44564C3F.2040609@aviawest.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

UPS does not protect against the tech behind the rack unplugging the 
power cable, or an accidental power cycle from exercising the wrong 
switch. :)  Both are probably more common causes of failure than a total 
power outage.

Erik Myllymaki wrote:
> I have been in discussion with 3ware support and after adjusting some 
> settings, the 3ware card in RAID 1 gets better performance than the 
> single drive. I guess this had everything to do with the write (and 
> maybe read?) cache.
>
> Of course now i am in a dangerous situation - using volatile write 
> cache without a BBU.
>
> If I were to use a UPS to ensure a soft shutdown in the event of power 
> loss, am I somewhat as safe as if I were to purchase a BBU for this 
> RAID card?
>
>
>
> Thanks.
>
> Mark Lewis wrote:
>> It's also possible that the single SATA drive you were testing (or the
>> controller it was attached to) is lying about fsync and performing write
>> caching behind your back, whereas your new controller and drives are
>> not.
>>
>> You'll find a lot more info on the archives of this list about it, but
>> basically if your application is committing a whole lot of small
>> transactions, then it will run fast (but not safely) on a drive which
>> lies about fsync, but slower on a better disk subsystem which doesn't
>> lie about fsync.
>>
>> Try running a test with fsync=off with your new equipment and if it
>> suddenly starts running faster, then you know that's the problem.
>> You'll either have a choice of losing all of your data the next time the
>> system shuts down uncleanly but being fast, or of running slow, or of
>> fixing the applications to use chunkier transactions.
>>
>> -- Mark
>>
>> On Fri, 2006-04-28 at 13:36 -0400, Vivek Khera wrote:
>>> On Apr 28, 2006, at 11:37 AM, Erik Myllymaki wrote:
>>>
>>>> When I had this installed on a single SATA drive running from the  
>>>> PE1800's on-board SATA interface, this operation took anywhere 
>>>> from  65-80 seconds.
>>>>
>>>> With my new RAID card and drives, this operation took 272 seconds!?
>>> switch it to RAID10 and re-try your experiment.  if that is fast,  
>>> then you know your raid controller does bad RAID5.
>>>
>>> anyhow, I have in one server (our office mail server and part-time  
>>> development testing box) an adaptec SATA RAID from dell.  it is  
>>> configured for RAID5 and does well for normal office stuff, but 
>>> when  we do postgres tests on it, it just is plain old awful.
>>>
>>> but I have some LSI based cards on which RAID5 is plenty fast and  
>>> suitable for the DB, but those are SCSI.
>>>
>>> For what it is worth, the Dell PE1850 internal PERC4/Si card is  
>>> wicked fast when hooked up with a pair of U320 SCSI drives.
>>>
>>>
>>>
>>> ---------------------------(end of 
>>> broadcast)---------------------------
>>> TIP 3: Have you checked our extensive FAQ?
>>>
>>>                http://www.postgresql.org/docs/faq
>>
>> ---------------------------(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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend