----- Original Message -----
From: "Greg Smith" <gsmith@xxxxxxxxxxxxx>
To: <pgsql-performance@xxxxxxxxxxxxxx>
Sent: Thursday, March 13, 2008 4:27 PM
Subject: Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
On Thu, 13 Mar 2008, Joshua D. Drake wrote:
Greg Smith <gsmith@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
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)
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
