Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 4DE592E004A for ; Thu, 13 Mar 2008 13:02:22 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 91078-07 for ; Thu, 13 Mar 2008 13:01:53 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from westnet.com (westnet.com [216.187.52.2]) by postgresql.org (Postfix) with ESMTP id 6165D2E2368 for ; Thu, 13 Mar 2008 13:01:54 -0300 (ADT) Received: from westnet.com (localhost [127.0.0.1]) by westnet.com (8.14.0/8.14.0) with ESMTP id m2DG1oa5002815; Thu, 13 Mar 2008 12:01:50 -0400 (EDT) Received: from localhost (gsmith@localhost) by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id m2DG1o38002809; Thu, 13 Mar 2008 12:01:50 -0400 (EDT) X-Authentication-Warning: westnet.com: gsmith owned process doing -bs Date: Thu, 13 Mar 2008 12:01:50 -0400 (EDT) From: Greg Smith X-X-Sender: gsmith@westnet.com To: Craig James cc: "Joshua D. Drake" , pgsql-performance@postgresql.org Subject: Re: Benchmark: Dell/Perc 6, 8 disk RAID 10 In-Reply-To: <47D9402A.3050903@emolecules.com> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/284 X-Sequence-Number: 29238 On Thu, 13 Mar 2008, Craig James 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. I suspect most of the improvement you saw from Joshua's recommendations was from raising checkpoint_segments. > $ pgbench -c 10 -t 10000 -v test -U test > scaling factor: 1 > number of clients: 10 A scaling factor of 1 means you are operating on a positively trivial 16MB database. It also means there's exactly one entry in a table that every client updates on every transactions. You have 10 clients, and they're all fighting over access to it. If you actually want something that approaches useful numbers here, you need to at run 'pgbench -i -s 10' to get a scaling factor of 10 and a 160MB database. Interesting results on this class of hardware are when you set scaling to 100 or more (100=1.6GB database). See http://www.westnet.com/~gsmith/content/postgresql/pgbench-scaling.htm for some examples of how that works, from a less powerful system than yours. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD