Re: hardare config question

From: Erik Myllymaki <erik(dot)myllymaki(at)aviawest(dot)com>
To: Tom Arthurs <tarthurs(at)jobflash(dot)com>
Cc: Mark Lewis <mark(dot)lewis(at)mir3(dot)com>, Vivek Khera <vivek(at)khera(dot)org>, Pgsql performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: hardare config question
Date: 2006-05-01 18:43:20
Message-ID: 445656C8.6070308@aviawest.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

good points, thanks.

Tom Arthurs wrote:
> 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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Luke Lonergan 2006-05-01 18:50:37 Re: hardare config question
Previous Message Chris Mckenzie 2006-05-01 18:40:41 Postgres 7.4 and vacuum_cost_delay.