Re: Benchmark: Dell/Perc 6, 8 disk RAID 10 - Mailing list pgsql-performance
From | justin |
---|---|
Subject | Re: Benchmark: Dell/Perc 6, 8 disk RAID 10 |
Date | |
Msg-id | 001801c8855c$ff25c550$2801a8c0@JDell Whole thread Raw |
In response to | count * performance issue ("sathiya psql" <sathiya.psql@gmail.com>) |
Responses |
Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
|
List | pgsql-performance |
----- 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)
pgsql-performance by date: