Thread: Re: Postgresql Performance on an HP DL385 and
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 > > > > > >
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
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
>
>
>
>
>
>