Steve,

At the end of the day it seems that you've got a support issue with the
SmartArray RAID adapter from HP.

Last I tried that I found that they don't write the cciss driver, don't
test it for performance on Linux and don't make any claims about it's
performance on Linux.

That said - can you contact them through HP tech support and report back
to this list what you find out?

- Luke
> -----Original Message-----
> From: Steve Poe [mailto:steve.poe@gmail.com]
> Sent: Tuesday, August 08, 2006 11:33 PM
> To: Luke Lonergan
> Cc: Alex Turner; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Postgresql Performance on an HP DL385 and
>
> Luke,
>
> I check dmesg one more time and I found this regarding the
> cciss driver:
>
> Filesystem "cciss/c1d0p1": Disabling barriers, not supported
> by the underlying device.
>
> Don't know if it means anything, but thought I'd mention it.
>
> Steve
>
>
> On 8/8/06, Steve Poe <steve.poe@gmail.com> 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.
>
> 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@greenplum.com
> <mailto:LLonergan@greenplum.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
>
>
>
>
>
>


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

Luke,

I will do that. If it is the general impression that this server should
perform well with Postgresql, Are the RAID cards, the 6i and 642 sufficient
to your knowledge? I am wondering if it is the disc array itself.

Steve

On 8/8/06, Luke Lonergan <LLonergan@greenplum.com> wrote:
>
> Steve,
>
> At the end of the day it seems that you've got a support issue with the
> SmartArray RAID adapter from HP.
>
> Last I tried that I found that they don't write the cciss driver, don't
> test it for performance on Linux and don't make any claims about it's
> performance on Linux.
>
> That said - can you contact them through HP tech support and report back
> to this list what you find out?
>
> - Luke
> > -----Original Message-----
> > From: Steve Poe [mailto:steve.poe@gmail.com]
> > Sent: Tuesday, August 08, 2006 11:33 PM
> > To: Luke Lonergan
> > Cc: Alex Turner; pgsql-performance@postgresql.org
> > Subject: Re: [PERFORM] Postgresql Performance on an HP DL385 and
> >
> > Luke,
> >
> > I check dmesg one more time and I found this regarding the
> > cciss driver:
> >
> > Filesystem "cciss/c1d0p1": Disabling barriers, not supported
> > by the underlying device.
> >
> > Don't know if it means anything, but thought I'd mention it.
> >
> > Steve
> >
> >
> > On 8/8/06, Steve Poe <steve.poe@gmail.com> 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.
> >
> > 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@greenplum.com
> > <mailto:LLonergan@greenplum.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
> >
> >
> >
> >
> >
> >
>
>