Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id AB26564FCBE for ; Wed, 24 Dec 2008 10:13:55 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 12611-02 for ; Wed, 24 Dec 2008 10:13:52 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail137158.authsmtp.com (outmail137158.authsmtp.com [62.13.137.158]) by mail.postgresql.org (Postfix) with ESMTP id 4007B64FC39 for ; Wed, 24 Dec 2008 10:13:52 -0400 (AST) Received: from mail-c188.authsmtp.com (mail-c188.authsmtp.com [62.13.128.25]) by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id mBOEDlkv001727; Wed, 24 Dec 2008 14:13:47 GMT Received: from [192.168.0.3] (85-211-226-82.dyn.gotadsl.co.uk [85.211.226.82]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id mBOEDkTr076317; Wed, 24 Dec 2008 14:13:47 GMT Subject: Re: dbt-2 tuning results with postgresql-8.3.5 From: Simon Riggs To: Mark Wong Cc: "pgsql-performance@postgresql.org" , Selena Deckelmann , Gabrielle Roth In-Reply-To: <70c01d1d0812201654i5f55150ep619a6c7ff094470@mail.gmail.com> References: <70c01d1d0812201654i5f55150ep619a6c7ff094470@mail.gmail.com> Content-Type: text/plain Date: Wed, 24 Dec 2008 14:14:06 +0000 Message-Id: <1230128046.4793.1145.camel@ebony.2ndQuadrant> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Server-Quench: 14850432-d1c5-11dd-aecc-001871e930f4 X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksachtFagFbaVxS HGQLW1xEUVl7WGB/ bw0fZQBDYEtPQQdo VlZBQE1QEQdtHhxP W2xhJ20pE0dGf3hz ZEEsXHFSVAp7cU54 QkpXF3BSZDRldWEe BBRFJlYHIx5Kfh5N bVEqXXANN2FJBC9q VzwLEgofGg96HWxZ SB1IdxoOXEAKGDF0 XR0ZADEzBgUaRjkz ZwQhMUITBksKK0F3 YR16Hw9w X-Authentic-SMTP: 61633235383639.cat.dmpriest.net.uk:1378/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200812/208 X-Sequence-Number: 32244 Hi Mark, Good to see you producing results again. On Sat, 2008-12-20 at 16:54 -0800, Mark Wong wrote: > Here are links to how the throughput changes when increasing shared_buffers: > > http://pugs.postgresql.org/node/505 Only starnge thing here is the result at 22528MB. It's the only normal one there. Seems to be a freeze occurring on most tests around the 30 minute mark, which delays many backends and reduces writes. Reduction in performance as shared_buffers increases looks normal. Increase wal_buffers, but look for something else as well. Try to get a backtrace from when the lock up happens. It may not be Postgres? > And another series of tests to show how throughput changes when > checkpoint_segments are increased: > > http://pugs.postgresql.org/node/503 > > The links go to a graphical summary and raw data. Note that the > maximum theoretical throughput at this scale factor is approximately > 12000 notpm. > > My first glance takes tells me that the system performance is quite > erratic when increasing the shared_buffers. I'm also not what to > gather from increasing the checkpoint_segments. Is it simply that the > more checkpoint segments you have, the more time the database spends > fsyncing when at a checkpoint? I would ignore the checkpoint_segment tests because you aren't using a realistic value of shared_buffers. I doubt any such effect is noticeable when you use a realistic value determined from set of tests 505. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support