From: justin <justin@emproshunts.com>
To: Greg Smith <gsmith@gregsmith.com>
To: pgsql-performance@postgresql.org
Subject: Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
Date: Thu, 13 Mar 2008 17:53:04 -0500
Message-ID: <001801c8855c$ff25c550$2801a8c0@JDell> (raw)
References: <f966c2ee0803052142l6a105678jfe2da92a0d9371@mail.gmail.com>
<f966c2ee0803052143k4570d771o6c300647d3b987d@mail.gmail.com>
<20080306060829.GA21084@a-kretschmer.de>
<bf54be870803052215y5bb56235k5ea05ada1d701022@mail.gmail.com>
<47CF8EA6.8070503@mark.mielke.cc>
<20080306063643.GB21084@a-kretschmer.de>
<f966c2ee0803052243w723e2866gbfc37128620d1c6d@mail.gmail.com>
<B94D3180-BB72-43EB-BA1E-90CF53705386@fastcrypt.com>
<f966c2ee0803060358k14dd7374h8ef3f4ca0818b04@mail.gmail.com>
<3E9C3A51-C28E-4B75-9739-E344DAC72880@fastcrypt.com>
<f966c2ee0803060443j3d9c1b66x5f59e00d084e841c@mail.gmail.com>
<Pine.GSO.4.64.0803060813570.11897@westnet.com>
<47D00DB2.7040007@emolecules.com>
<18451.1204824562@sss.pgh.pa.us>
<47D0AFC1.5070305@emolecules.com>
<47D8B3B6.3010606@emolecules.com>
<20080312225554.52f6275b@commandprompt.com>
<47D9402A.3050903@emolecules.com>
<Pine.GSO.4.64.0803131151430.24943@westnet.com>
<20080313140618.3449ba58@commandprompt.com>
<Pine.GSO.4.64.0803131710520.5221@w estnet.com>
----- Original Message -----
From: "Greg Smith" <gsmith@gregsmith.com>
To: <pgsql-performance@postgresql.org>
Sent: Thursday, March 13, 2008 4:27 PM
Subject: Re: [PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10
> On Thu, 13 Mar 2008, Joshua D. Drake wrote:
>
>> Greg Smith <gsmith@gregsmith.com> wrote:
>>>>> wal_sync_method = open_sync
>>>
>>> There was a bug report I haven't had a chance to investigate yet that
>>> suggested some recent Linux versions have issues when using
>>> open_sync. I'd suggest popping that back to the default for now
>>> unless you have time to really do a long certification process that
>>> your system runs reliably with it turned on.
>>
>> Well the default would be ugly, that's fsync, fdatasync is probably a
>> better choice in that case.
>
> I haven't found fdatasync to be significantly better in my tests on Linux
> but I never went out of my way to try and quantify it. My understanding
> is that some of the write barrier implementation details on ext3
> filesystems make any sync call a relatively heavy operation but I haven't
> poked at the code yet to figure out why.
>
> There are really some substantial gains for WAL-heavy loads under Linux
> just waiting for someone to dig into this more. For example, I have a
> little plan sitting here to allow opening the WAL files with noatime even
> if the rest of the filesystem can't be mounted that way, which would
> collapse one of the big reasons to use a separate WAL disk.
>
> --
> * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
I'm ran pgbench from my laptop to the new server
My laptop is dual core with 2 gigs of ram and 1 gig enthernet connection to
server. so i don't think the network is going to be a problem in the test.
When i look at the server memory its only consuming 463 megs. I have the
effective cache set at 12 gigs and sharebuffer at 100megs and work mem set
to 50megs
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 1
number of transactions per client: 10
number of transactions actually processed: 10/10
tps = 20.618557 (including connections establishing)
tps = 20.618557 (excluding connections establishing)
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 10
number of transactions per client: 10
number of transactions actually processed: 100/100
tps = 18.231541 (including connections establishing)
tps = 18.231541 (excluding connections establishing)
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 10
number of transactions per client: 100
number of transactions actually processed: 1000/1000
tps = 19.116073 (including connections establishing)
tps = 19.116073 (excluding connections establishing)
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 40
number of transactions per client: 1000
number of transactions actually processed: 40000/40000
tps = 20.368217 (including connections establishing)
tps = 20.368217 (excluding connections establishing)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: justin@emproshunts.com, gsmith@gregsmith.com
Subject: Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
In-Reply-To: <001801c8855c$ff25c550$2801a8c0@JDell>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox