Re: hardare config question - Mailing list pgsql-performance
From | Mark Lewis |
---|---|
Subject | Re: hardare config question |
Date | |
Msg-id | 1146507353.10239.25.camel@archimedes Whole thread Raw |
In response to | Re: hardare config question (Erik Myllymaki <erik.myllymaki@aviawest.com>) |
List | pgsql-performance |
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
pgsql-performance by date: