Обсуждение: Re: Postgresql Performance on an HP DL385 and

I agree, I think these say you are getting 240MB/s sequential reads and 1000 seeks per second.

That's pretty much the best you'd expect.

- Luke

Sent from my GoodLink synchronized handheld (www.good.com)


 -----Original Message-----
From:     Alex Turner [mailto:armtuk@gmail.com]
Sent:    Tuesday, August 08, 2006 02:40 AM Eastern Standard Time
To:    steve.poe@gmail.com
Cc:    Luke Lonergan; pgsql-performance@postgresql.org
Subject:    Re: [PERFORM] Postgresql Performance on an HP DL385 and

These number are pretty darn good for a four disk RAID 10, pretty close to
perfect infact.  Nice advert for the 642 - I guess we have a Hardware RAID
controller than will read indpendently from mirrors.

Alex

On 8/8/06, Steve Poe <steve.poe@gmail.com> wrote:
>
> Luke,
>
> Here are the results of two runs of 16GB file tests on XFS.
>
> scsi disc array
> xfs ,16G,81024,99,153016,24,73422,10,82092,97,243210,17,1043.1
> ,0,16,3172,7,+++++,+++,2957,9,3197,10,+++++,+++,2484,8
> scsi disc array
> xfs ,16G,83320,99,155641,25,73662,10,81756,96,243352,18,1029.1
> ,0,16,3119,10,+++++,+++,2789,7,3263,11,+++++,+++,2014,6
>
> Thanks.
>
> Steve
>
>
>
> > Can you run bonnie++ version 1.03a on the machine and report the results
> > here?
> >
> > It could be OK if you have the latest Linux driver for cciss, someone
> has
> > reported good results to this list with the latest, bleeding edge
> version of
> > Linux (2.6.17).
> >
> > - Luke
> >
>
>
> >
> >
> > ---------------------------(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 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
>

Steve,

On 8/8/06 8:01 AM, "Steve Poe" <steve.poe@gmail.com> wrote:

> Thanks for the feedback.  I use the same database test that I've run a Sun
> dual Opteron with 4Gb RAM and (2) four disk arrays in RAID10. The sun box with
> one disc on an LSI MegaRAID 2-channel adapter outperforms this HP box. I
> though I was doing something wrong or there is something wrong with the box.

Given the circumstances (benchmarked I/O is great, comparable perf on
another box with single disk is better), seems that one of:
1) something wrong with the CPU/memory on the box
2) something with the OS version / kernel
3) something with the postgres configuration

Can you post the database benchmark results?

- Luke

Steve,

On 8/8/06 9:57 AM, "Steve Poe" <steve.poe@gmail.com> wrote:

> On the Sun box, with 4 discs (RAID10) to one channel on the LSI RAID card, I
> see an average TPS around 70. If I ran this off of one disc, I see an average
> TPS of 32.
>
> on the HP box, with 6-discs in RAID10 and 1 spare. I see a TPS of 34. I don't
> have my vmstat reports with me, but I recall the CPU utilitization on the HP
> was about 50% higher. I need to check on this.

Sounds like there are a few moving parts here, one of which is the ODBC
driver.

First - using 7.4.x postgres is a big variable - not much experience on this
list with 7.4.x anymore.

What OS versions are on the two machines?

What is the network configuration of each - is a caching DNS server
available to each?  What are the contents of /etc/resolv.conf?

Have you run "top" on the machines while the benchmark is running?  What is
the top running process, what is it doing (RSS, swap, I/O wait, etc)?

Are any of the disks not healthy?  Do you see any I/O errors in dmesg?

Note that tarring up the database directory and untarring it actually
changes the block layout of the files on the disk from what the database
might have done when it was created.  When you create a tar archive of the
files in the DB directory, their contents will be packed in file name order
in the tar archive and unpacked that way as well.  By comparison, the
ordering when the database lays them on disk might have been quite
different.  This doesn't impact the problem you describe as you are
unpacking the tar file on both machines to start the process (right?).

- Luke

> Are any of the disks not healthy?  Do you see any I/O errors in dmesg?

Luke,

In my vmstat report, I it is an average per minute not per-second. Also,
I found that in the first minute of the very first run, the HP's "bi"
value hits a high of 221184 then it tanks after that.

Steve