X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 42CCF9FB366 for ; Tue, 8 Aug 2006 13:57:54 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 96037-07 for ; Tue, 8 Aug 2006 13:57:45 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey- Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by postgresql.org (Postfix) with ESMTP id 347389FB365 for ; Tue, 8 Aug 2006 13:57:44 -0300 (ADT) Received: by nf-out-0910.google.com with SMTP id n28so314671nfc for ; Tue, 08 Aug 2006 09:57:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=OUF5XBxtkcjtUyMWNoU+kzM3PBlQKXGvZIRN7lU3miyrzOIYYOunrkB0ZJOzkM/WegaosydYcmatK/uIF1naGZNLueXRjnAEJvGWmtCFRllT/VlOuT9FR8cyUQBpzH1TKfBmifQjSILOZiuqw+kST2+G4Iq5wjkYGFUKoWRo7f0= Received: by 10.78.177.3 with SMTP id z3mr2833187hue; Tue, 08 Aug 2006 09:57:43 -0700 (PDT) Received: by 10.78.33.3 with HTTP; Tue, 8 Aug 2006 09:57:43 -0700 (PDT) Message-ID: <721b21dc0608080957k166a7bc5t72cb3cf076e6da01@mail.gmail.com> Date: Tue, 8 Aug 2006 09:57:43 -0700 From: "Steve Poe" To: "Luke Lonergan" Subject: Re: Postgresql Performance on an HP DL385 and Cc: "Alex Turner" , pgsql-performance@postgresql.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16251_31296065.1155056263259" References: <721b21dc0608080801l5fb6534ey7094774ff79a323b@mail.gmail.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.934 tagged_above=0 required=5 tests=AWL, DNS_FROM_RFC_ABUSE, HTML_10_20, HTML_MESSAGE, SPF_PASS X-Spam-Level: X-Archive-Number: 200608/105 X-Sequence-Number: 20290 ------=_Part_16251_31296065.1155056263259 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Luke, Here's some background: I use Pg 7.4.13 (I've tested as far back as 7.4.8). I use an 8GB data with a program called odbc-bench. I run an 18 minute test. With each run, HP box excluded, I unmount the discs involved, reformat, un-tar the backup of PGDATA and pg_xlog back on the discs, start-up Postgresql, then run the odbc-bench. On the Sun box, I've benchmarked an average of 3 to 4 runs with each disc (up to 8) in succession in RAID0, RAID5, and RAID10 where applicable. I've done with with pg_xlog on the same discs as PGDATA and separately, so I've felt like I had a good understanding of how the performance works. I've notice performance seems to level off at around 6 discs with another 10-15% with two more discs. When I run odbc-bench, I also run vmstat in the background (through a python script) which averages/summarzies the high/low/average of each category for each minute then a final summary after the run. 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. Steve On 8/8/06, Luke Lonergan wrote: > > Steve, > > On 8/8/06 8:01 AM, "Steve Poe" 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 > > > ------=_Part_16251_31296065.1155056263259 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Luke,

Here's some background:
I use Pg 7.4.13 (I've tested as far back as 7.4.8). I use an 8GB data with a program called odbc-bench. I run an 18 minute test. With each run, HP box excluded, I unmount the discs involved, reformat, un-tar the backup of PGDATA and pg_xlog back on the discs, start-up Postgresql, then run the odbc-bench.

On the Sun box, I've benchmarked an average of 3 to 4 runs with each disc (up to 8) in succession in RAID0, RAID5, and RAID10 where applicable. I've done with with pg_xlog on the same discs as PGDATA and separately, so I've felt like I had a good understanding of how the performance works. I've notice performance seems to level off at around 6 discs with another 10-15% with two more discs.

When I run odbc-bench, I also run vmstat in the background (through a python script) which averages/summarzies the high/low/average of each category for each minute then a final summary after the run.

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.

Steve







On 8/8/06, Luke Lonergan <llonergan@greenplum.com> wrote:
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



------=_Part_16251_31296065.1155056263259--