Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 487EFB5DBBE for ; Sun, 14 Aug 2011 21:29:09 -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 91333-07 for ; Mon, 15 Aug 2011 00:29:02 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mail.postgresql.org (Postfix) with ESMTP id 8597AB5D803 for ; Sun, 14 Aug 2011 21:29:02 -0300 (ADT) Received: from [192.168.1.6] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MMWPG-1QwcfV2MBi-008K7t; Mon, 15 Aug 2011 02:29:00 +0200 Message-ID: <4E48684A.2070909@2ndQuadrant.com> Date: Sun, 14 Aug 2011 20:28:58 -0400 From: Greg Smith User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110702 Icedove/3.0.11 MIME-Version: 1.0 To: tv@fuzzy.cz CC: pgsql-performance@postgresql.org Subject: Re: strange pgbench results (as if blocked at the end) References: <2f9ba8ed6e4ed11d9a6d236cb4d2a2ec.squirrel@sq.gransy.com> <4E45EAD3.9030102@2ndQuadrant.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:Djle+ygt7Xz4FXBpEatrroRK9PdqqYTbsOq17aRP2Oc bzuWwVuLLqEQkV+nFUdW67D8KFGDQZXW/f6YGRGsF1IMq1AEOv IiemdJzrKm0etoy+/lKxA/gjiSC6dCIAG5h5pqiSaALyev90aM KPc1mq731+5u6uh2qi8Q+aO0sal7NpVeUa37rWLd67EMU5/FOw HH9FGDf+b59So0EEOVY8BeXWdTvJV0LOkXIAhMygVw= 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: 201108/162 X-Sequence-Number: 44609 On 08/14/2011 08:51 AM, tv@fuzzy.cz wrote: > I've increased the test duration to 10 minutes, decreased the > checkpoint timeout to 4 minutes and a checkpoint is issued just before > the pgbench. That way the starting position should be more or less the > same for all runs. > That's basically what I settled on for pgbench-tools. Force a checkpoint just before the test, so the beginning of each run is aligned more consistently, then run for long enough that you're guaranteed at least one checkpoint finishes[1] (and you might see more than one if you fill checkpoint_segments fast enough). I never bothered trying to compress that test cycle down by decreasing checkpoint_timeout. There's already too many things you need to do in order to get this test working well, and I didn't want to include a change I'd never recommend people make on a production server in the mix. [1] If your checkpoint behavior goes pathological, for example the extended checkpoints possible when the background writer fsync queue fills, it's not actually guaranteed that the checkpoint will finish within 5 minutes after it starts. So a 10 minute run doesn't assure you'll a checkpoint begin and end in all circumstances, but it is the expected case. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us