X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 8C69E9F9B76 for ; Mon, 1 May 2006 15:50:56 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 98232-08 for ; Mon, 1 May 2006 15:50:49 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.mi8.com (d01gw04.mi8.com [63.240.6.44]) by postgresql.org (Postfix) with ESMTP id 896E59F9586 for ; Mon, 1 May 2006 15:50:49 -0300 (ADT) Received: from 172.16.1.148 by mail.mi8.com with ESMTP (- Welcome to Mi8 Corporation www.Mi8.com (D4)); Mon, 01 May 2006 14:50:40 -0400 X-Server-Uuid: C8FB4D43-1108-484A-A898-3CBCC7906230 Received: from MI8NYCMAIL06.Mi8.com ([172.16.1.160]) by D01HOST02.Mi8.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 May 2006 14:50:40 -0400 Received: from 67.103.45.218 ([67.103.45.218]) by MI8NYCMAIL06.Mi8.com ( [172.16.1.219]) via Exchange Front-End Server mi8owa.mi8.com ( [172.16.1.104]) with Microsoft Exchange Server HTTP-DAV ; Mon, 1 May 2006 18:50:39 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Mon, 01 May 2006 11:50:37 -0700 Subject: Re: hardare config question From: "Luke Lonergan" To: erik.myllymaki@aviawest.com, "Tom Arthurs" cc: "Mark Lewis" , "Vivek Khera" , "Pgsql performance" Message-ID: Thread-Topic: [PERFORM] hardare config question Thread-Index: AcZtT4dQbv4RmOAKQ/WY2aKjMGYsGwAAJsry In-Reply-To: <445656C8.6070308@aviawest.com> MIME-Version: 1.0 X-OriginalArrivalTime: 01 May 2006 18:50:40.0076 (UTC) FILETIME=[245158C0:01C66D50] X-WSS-ID: 6848870A20C53757592-01-01 Content-Type: multipart/alternative; boundary=B_3229329037_1451736 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/15 X-Sequence-Number: 18802 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3229329037_1451736 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable We use the 3Ware BBUs and they=B9re very nice, they self monitor and let you know about their capacity if it=B9s a problem. - Luke On 5/1/06 11:43 AM, "Erik Myllymaki" wrote: > good points, thanks. >=20 > 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 tot= al >> > power outage. >> > >> > Erik Myllymaki wrote: >>> >> I have been in discussion with 3ware support and after adjusting som= e >>> >> 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 pow= er >>> >> 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 a= re >>>> >>> 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 wh= ich >>>> >>> lies about fsync, but slower on a better disk subsystem which does= n't >>>> >>> lie about fsync. >>>> >>> >>>> >>> Try running a test with fsync=3Doff with your new equipment and if i= t >>>> >>> 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 ti= me 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 seco= nds!? >>>>> >>>> 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-ti= me >>>>> >>>> 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 an= d >>>>> >>>> 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 >=20 > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend >=20 >=20 --B_3229329037_1451736 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Re: [PERFORM] hardare config question We us= e the 3Ware BBUs and they’re very nice, they self monitor and let you = know about their capacity if it’s a problem.

- Luke


On 5/1/06 11:43 AM, "Erik Myllymaki" <erik.myllymaki@aviawest.= com> wrote:

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 s= ome
>> settings, the 3ware card in RAID 1 gets better performance than th= e
>> single drive. I guess this had everything to do with the write (an= d
>> 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 p= ower
>> loss, am I somewhat as safe as if I were to purchase a BBU for thi= s
>> 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 perfor= ming write
>>> caching behind your back, whereas your new controller and driv= es 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 sma= ll
>>> transactions, then it will run fast (but not safely) on a driv= e which
>>> lies about fsync, but slower on a better disk subsystem which = doesn't
>>> lie about fsync.
>>>
>>> Try running a test with fsync=3Doff with your new equipment and = if it
>>> suddenly starts running faster, then you know that's the probl= em.
>>> You'll either have a choice of losing all of your data the nex= t 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 runni= ng 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 t= hat is fast,
>>>> then you know your raid controller does bad RAID5.
>>>>
>>>> anyhow, I have in one server (our office mail server and p= art-time
>>>> development testing box) an adaptec SATA RAID from dell. &= nbsp;it is
>>>> configured for RAID5 and does well for normal office stuff= , but
>>>> when  we do postgres tests on it, it just is plain ol= d awful.
>>>>
>>>> but I have some LSI based cards on which RAID5 is plenty f= ast and
>>>> suitable for the DB, but those are SCSI.
>>>>
>>>> For what it is worth, the Dell PE1850 internal PERC4/Si ca= rd is
>>>> wicked fast when hooked up with a pair of U320 SCSI drives= .
>>>>
>>>>
>>>>
>>>> ---------------------------(end of
>>>> broadcast)---------------------------
>>>> TIP 3: Have you checked our extensive FAQ?
>>>>
>>>>          &nbs= p;     http://www.postgresql.org/docs/faq
>>>
>>> ---------------------------(end of broadcast)-----------------= ----------
>>> TIP 9: In versions below 8.0, the planner will ignore your des= ire to
>>>        choose an index scan= if your joining column's datatypes do not
>>>        match
>>
>> ---------------------------(end of broadcast)---------------------= ------
>> TIP 6: explain analyze is your friend

---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend



 --B_3229329037_1451736--