Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id CD3EE632624 for ; Tue, 29 Jun 2010 22:23:49 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 41146-04 for ; Wed, 30 Jun 2010 01:23:42 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mail.postgresql.org (Postfix) with ESMTP id 873DE6327AE for ; Tue, 29 Jun 2010 22:23:42 -0300 (ADT) Received: from [10.0.12.23] ([217.41.237.250]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MSFW3-1OaCES1mVn-00T4mi; Wed, 30 Jun 2010 03:23:39 +0200 Message-ID: <4C2A9C99.40303@2ndquadrant.com> Date: Wed, 30 Jun 2010 02:23:37 +0100 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Craig James CC: pgsql-performance@postgresql.org Subject: Re: pgbench results on a new server References: <4BBCFB12.1010306@emolecules.com> <4BBD3A17.90209@emolecules.com> <4C23FD52.40508@emolecules.com> <23596.1277438692@sss.pgh.pa.us> <4C24B3BB.3070901@emolecules.com> <2286.1277477230@sss.pgh.pa.us> <4C24D679.7030701@emolecules.com> <6203.1277485291@sss.pgh.pa.us> <4C24FB0D.4020701@emolecules.com> <4C24FD82.4070100@2ndquadrant.com> <4C28D809.7070707@emolecules.com> In-Reply-To: <4C28D809.7070707@emolecules.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18K1Ybjy6lScvQspn/OKCq3sBMvMPU0SBaAPa9 ix+xXvWJ/SF9VRe5FXzaK9290U/LxCO9WmLmA9/SSAtEhsujQM 9bGbgG9OAowqHpka+UjYZqae7DUwTBj X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201006/522 X-Sequence-Number: 39378 Craig James wrote: > synchronous_commit = off > full_page_writes = off I don't have any numbers handy on how much turning synchronous_commit and full_page_writes off improves performance on a system with a battery-backed write cache. Your numbers are therefore a bit inflated against similar ones that are doing a regular sync commit. Just something to keep in mind when comparing against other people's results. Also, just as a general comment, increase in work_mem and effective_cache_size don't actually do anything to the built-in pgbench test results. >> General numbers are OK, the major drop going from 30 to 40 clients is >> larger than it should be. I'd suggest running the 40 client count one >> again to see if that's consistent. > > It is consistent. When I run pgbench from a different server, I get > this: > > pgbench -c40 -t 2500 -U test > tps = 7999 > > pgbench -c100 -t 1000 -U test > tps = 6693 Looks like you're just running into the limitations of the old pgbench code failing to keep up with high client count loads when run on the same system as the server. Nothing to be concerned about--that the drop is only small with the pgbench client remote says there's not actually a server problem here. With that sorted out, your system looks in the normal range for the sort of hardware you're using. I'm always concerned about the potential reliability issues that come with async commit and turning off full page writes though, so you might want to re-test with those turned on and see if you can live with the results. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us