X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 8B9D19FB306 for ; Fri, 18 Aug 2006 18:34:40 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 52883-02 for ; Fri, 18 Aug 2006 21:34:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from exprod6og50.obsmtp.com (exprod6og50.obsmtp.com [64.18.1.181]) by postgresql.org (Postfix) with SMTP id 481459FB214 for ; Fri, 18 Aug 2006 18:32:57 -0300 (ADT) Received: from source ([63.240.6.47]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Fri, 18 Aug 2006 14:32:54 PDT Received: from 172.16.1.25 by mail.Mi8.com with ESMTP (- Welcome to Mi8 Corporation www.Mi8.com (D1)); Fri, 18 Aug 2006 17:32:47 -0400 X-Server-Uuid: 241911D6-425B-44B9-A073-E3FE0F8FC774 Received: from MI8NYCMAIL06.Mi8.com ([172.16.1.160]) by D01HOST03.Mi8.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Aug 2006 17:32:47 -0400 Received: from 63.80.24.130 ([63.80.24.130]) by MI8NYCMAIL06.Mi8.com ( [172.16.1.219]) via Exchange Front-End Server mi8owa.mi8.com ( [172.16.1.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 18 Aug 2006 21:32:46 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 18 Aug 2006 14:32:44 -0700 Subject: Re: Postgresql Performance on an HP DL385 and From: "Luke Lonergan" To: "Steve Poe" cc: "Scott Marlowe" , "Michael Stone" , pgsql-performance@postgresql.org Message-ID: Thread-Topic: [PERFORM] Postgresql Performance on an HP DL385 and Thread-Index: AcbDDddBFcSLVi8BEduD2wAWy4o9DA== In-Reply-To: <721b21dc0608181200h308912b0mf2ccfb1d97970f03@mail.gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 18 Aug 2006 21:32:47.0300 (UTC) FILETIME=[D938B040:01C6C30D] X-WSS-ID: 68F8EE754OS2747562-01-01 Content-Type: multipart/alternative; boundary=B_3238756364_1506691 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.997 tagged_above=0 required=5 tests=HTML_40_50, HTML_MESSAGE, RCVD_NUMERIC_HELO X-Spam-Level: * X-Archive-Number: 200608/311 X-Sequence-Number: 20496 > 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_3238756364_1506691 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Steve, One thing here is that =B3wal_sync_method=B2 should be set to =B3fdatasync=B2 and not =B3fsync=B2. In fact, the default is fdatasync, but because you have uncommented the standard line in the file, it is changed to =B3fsync=B2, which is a lot slower. This is a bug in the file defaults. That could speed things up quite a bit on the xlog. WRT the difference between the two systems, I=B9m kind of stumped. - Luke On 8/18/06 12:00 PM, "Steve Poe" wrote: >=20 > Luke,=20 >=20 >> ISTM that the main performance issue for xlog is going to be the rate at >> which fdatasync operations complete, and the stripe size shouldn't hurt >> that. >=20 > I thought so. However, I've also tried running the PGDATA off of the RAID= 1 as > a test and it is poor. >=20 > =20 >=20 >> What are your postgresql.conf settings for the xlog: how many logfiles, >> sync_method, etc? >=20 > wal_sync_method =3D fsync # the default varies across platforms: > # fsync, fdatasync, open_sync, or > open_datasync > # - Checkpoints - >=20 > checkpoint_segments =3D 14 # in logfile segments, min 1, 16MB each > checkpoint_timeout =3D 300 # range 30-3600, in seconds > #checkpoint_warning =3D 30 # 0 is off, in seconds > #commit_delay =3D 0 # range 0-100000, in microseconds > #commit_siblings =3D 5 >=20 > What stumps me is I use the same settings on a Sun box (dual Opteron 4GB = w/ > LSI MegaRAID 128M) with the same data. This is on pg 7.4.13. >=20 > =20 >=20 >>> > The 6-disc RAID10 you speak of is on the SmartArray 642 RAID adapter. >>=20 >> Interesting - the seek rate is very good for two drives, are they 15K RP= M? >=20 > Nope. 10K. RPM. =20 >=20 >=20 > HP's recommendation for testing is to connect the RAID1 to the second cha= nnel > off of the SmartArray 642 adapter since they use the same driver, and, > according to HP, I should not have to rebuilt the RAID1. >=20 > I have to send the new server to the hospital next week, so I have very l= ittle > testing time left. >=20 > Steve >=20 > =20 >=20 >=20 >=20 --B_3238756364_1506691 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Re: [PERFORM] Postgresql Performance on an HP DL385 and Steve= ,

One thing here is that “wal_sync_method” should be set to ̶= 0;fdatasync” and not “fsync”.  In fact, the default i= s fdatasync, but because you have uncommented the standard line in the file,= it is changed to “fsync”, which is a lot slower.  This is = a bug in the file defaults.

That could speed things up quite a bit on the xlog.

WRT the difference between the two systems, I’m kind of stumped.

- Luke


On 8/18/06 12:00 PM, "Steve Poe" <steve.poe@gmail.com> wrot= e:


Luke,

ISTM that the main performance issue for xlog is going = to be the rate at
which fdatasync operations complete, and the stripe size shouldn't hurt
that.

I thought so. However, I've also tried running the PGDATA off of the RAID1 = as a test and it is poor.

 

What are your postgresql.conf settings for the xlog: ho= w many logfiles,
sync_method, etc?

wal_sync_method =3D fsync # the default varies across platforms:
            &nb= sp;            &= nbsp;      # fsync, fdatasync, open_sync, or o= pen_datasync
# - Checkpoints -

checkpoint_segments =3D 14        # in log= file segments, min 1, 16MB each
checkpoint_timeout =3D 300        # range = 30-3600, in seconds
#checkpoint_warning =3D 30        # 0 is o= ff, in seconds
#commit_delay =3D 0          &nb= sp;    # range 0-100000, in microseconds
#commit_siblings =3D 5

What stumps me is I use the same settings on a Sun box (dual Opteron 4GB w/= LSI MegaRAID 128M) with the same data.  This is on pg 7.4.13.

 

> The 6-disc RAID10 you speak of is on the SmartArra= y 642 RAID adapter.

Interesting - the seek rate is very good for two drives, are they 15K RPM?<= BR>

Nope. 10K. RPM.  


HP's recommendation for testing is to connect the RAID1 to the second chann= el off of the SmartArray 642 adapter since they use the same driver, and, ac= cording to HP, I should not have to rebuilt the RAID1.

I have to send the new server to the hospital next week, so I have very lit= tle testing time left.

Steve

 




 --B_3238756364_1506691--