Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id B9BB52E0074 for ; Thu, 13 Mar 2008 18:54:19 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 86307-04 for ; Thu, 13 Mar 2008 18:54:16 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mail.emproshunts.com (mail.emproshunts.com [66.64.191.19]) by postgresql.org (Postfix) with ESMTP id 7F86B2E2DC4 for ; Thu, 13 Mar 2008 18:54:16 -0300 (ADT) Received: from [192.168.1.40] by mail.emproshunts.com (GMS 15.00.3626/KX5895.00.ca7cb0e7) with SMTP id douzgaaa for pgsql-performance@postgresql.org; Thu, 13 Mar 2008 17:54:13 -0400 Message-ID: <001801c8855c$ff25c550$2801a8c0@JDell> From: "justin" To: "Greg Smith" , References: <20080306060829.GA21084@a-kretschmer.de> <47CF8EA6.8070503@mark.mielke.cc> <20080306063643.GB21084@a-kretschmer.de> <3E9C3A51-C28E-4B75-9739-E344DAC72880@fastcrypt.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> <20080313140618.3449ba58@commandprompt.com> Subject: Re: Benchmark: Dell/Perc 6, 8 disk RAID 10 Date: Thu, 13 Mar 2008 17:53:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Originating-IP: [192.168.1.40] X-DNSBL: 0 X-AntiSpam: Checked for restricted content by Gordano's AntiSpam Software X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/290 X-Sequence-Number: 29244 ----- Original Message ----- From: "Greg Smith" To: 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 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)