Subject: Re: hardare config question
From: Mark Lewis <mark.lewis@mir3.com>
To: erik.myllymaki@aviawest.com
Cc: Vivek Khera <vivek@khera.org>,
	Pgsql performance <pgsql-performance@postgresql.org>
In-Reply-To: <44564C3F.2040609@aviawest.com>
References: <445236D5.5060509@aviawest.com>
	<3DFCE70E-E4BB-40AB-B27F-99E90E8159CA@khera.org>
	<1146246441.15712.41.camel@archimedes> <44564C3F.2040609@aviawest.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: MIR3, Inc.
Date: Mon, 01 May 2006 11:15:53 -0700
Message-Id: <1146507353.10239.25.camel@archimedes>
Mime-Version: 1.0

A UPS will make it less likely that the system will reboot and destroy
your database due to a power failure, but there are other causes for a
system reboot.

With a BBU, the only component that can fail and cause catastrophic data
loss is the RAID itself.

With a UPS, you are additionally vulnerable to OS crashes, failures in
non-RAID hardware, UPS failures, or anything else that would necessitate
a hard reboot.  

So a UPS is a decent replacement for a BBU only if you trust your app
server/OS more than you value your data.

-- Mark Lewis


On Mon, 2006-05-01 at 10:58 -0700, 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