Re: Postgresql Performance on an HP DL385 and

From: "Steve Poe" <steve(dot)poe(at)gmail(dot)com>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: "Luke Lonergan" <LLonergan(at)greenplum(dot)com>, "Alex Turner" <armtuk(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgresql Performance on an HP DL385 and
Date: 2006-08-09 21:11:37
Message-ID: 721b21dc0608091411g3a1a6e60q449de0d91020f9dc@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Jim,

I'll give it a try. However, I did not see anywhere in the BIOS
configuration of the 642 RAID adapter to enable writeback. It may have been
mislabled cache accelerator where you can give a percentage to read/write.
That aspect did not change the performance like the LSI MegaRAID adapter
does.

Steve

On 8/9/06, Jim C. Nasby <jnasby(at)pervasive(dot)com> wrote:
>
> On Tue, Aug 08, 2006 at 10:45:07PM -0700, Steve Poe wrote:
> > Luke,
> >
> > I thought so. In my test, I tried to be fair/equal since my Sun box has
> two
> > 4-disc arrays each on their own channel. So, I just used one of them
> which
> > should be a little slower than the 6-disc with 192MB cache.
> >
> > Incidently, the two internal SCSI drives, which are on the 6i adapter,
> > generated a TPS of 18.
>
> You should try putting pg_xlog on the 6 drive array with the data. My
> (limited) experience with such a config is that on a good controller
> with writeback caching enabled it won't hurt you, and if the internal
> drives aren't caching writes it'll probably help you a lot.
>
> > I thought this server would impressive from notes I've read in the
> group.
> > This is why I thought I might be doing something wrong. I stumped which
> way
> > to take this. There is no obvious fault but something isn't right.
> >
> > Steve
> >
> > On 8/8/06, Luke Lonergan <LLonergan(at)greenplum(dot)com> wrote:
> > >
> > >Steve,
> > >
> > >> Sun box with 4-disc array (4GB RAM. 4 167GB 10K SCSI RAID10
> > >> LSI MegaRAID 128MB). This is after 8 runs.
> > >>
> > >> dbserver-dual-opteron-centos,08/08/06,Tuesday,20,us,12,2,5
> > >> dbserver-dual-opteron-centos,08/08/06,Tuesday,20,sy,59,50,53
> > >> dbserver-dual-opteron-centos,08/08/06,Tuesday,20,wa,1,0,0
> > >> dbserver-dual-opteron-centos,08/08/06,Tuesday,20,id,45,26,38
> > >>
> > >> Average TPS is 75
> > >>
> > >> HP box with 8GB RAM. six disc array RAID10 on SmartArray 642
> > >> with 192MB RAM. After 8 runs, I see:
> > >>
> > >> intown-vetstar-amd64,08/09/06,Tuesday,23,us,31,0,3
> > >> intown-vetstar-amd64,08/09/06,Tuesday,23,sy,16,0,1
> > >> intown-vetstar-amd64,08/09/06,Tuesday,23,wa,99,6,50
> > >> intown-vetstar-amd64,08/09/06,Tuesday,23,id,78,0,42
> > >>
> > >> Average TPS is 31.
> > >
> > >Note that the I/O wait (wa) on the HP box high, low and average are all
> > >*much* higher than on the Sun box. The average I/O wait was 50% of one
> > >CPU, which is huge. By comparison there was virtually no I/O wait on
> > >the Sun machine.
> > >
> > >This is indicating that your HP machine is indeed I/O bound and
> > >furthermore is tying up a PG process waiting for the disk to return.
> > >
> > >- Luke
> > >
> > >
>
> --
> Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
> Pervasive Software http://pervasive.com work: 512-231-6117
> vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Jim C. Nasby 2006-08-09 21:20:46 Re: vacuuming
Previous Message Jim C. Nasby 2006-08-09 21:09:04 Re: Performance with 2 AMD/Opteron 2.6Ghz and 8gig