X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id C775A537CC for ; Mon, 25 Apr 2005 14:18:49 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 48301-03 for ; Mon, 25 Apr 2005 17:18:43 +0000 (GMT) Received: from mail.tecarta.com (66.238.115.135.ptr.us.xo.net [66.238.115.135]) by svr1.postgresql.org (Postfix) with ESMTP id 6091653757 for ; Mon, 25 Apr 2005 14:18:42 -0300 (ADT) Received: from mail pickup service by mail.tecarta.com with Microsoft SMTPSVC; Mon, 25 Apr 2005 10:21:47 -0700 Received: from mail.tecarta.com ([192.168.160.2]) by mail.tecarta.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Apr 2005 10:21:41 -0700 Received: from barracuda.tecarta.com ([192.168.160.200]) by mail.tecarta.com (SAVSMTP 3.1.0.29) with SMTP id M2005042510214128267 for ; Mon, 25 Apr 2005 10:21:41 -0700 X-ASG-Debug-ID: 1114449515-8064-15-0 X-Barracuda-URL: http://192.168.160.200:8000/cgi-bin/mark.cgi Received: from mail1 (mail1.hq.corp [192.168.160.5]) by barracuda.tecarta.com (Spam Firewall) with SMTP id E080120106BC for ; Mon, 25 Apr 2005 10:18:35 -0700 (PDT) Received: from [192.168.0.13] ([63.206.203.145]) by mail.tecarta.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Apr 2005 10:21:35 -0700 Message-ID: <426D265F.9080902@sfnet.cc> Date: Mon, 25 Apr 2005 10:18:23 -0700 From: Steve Poe User-Agent: Mozilla Thunderbird 1.0 (X11/20041228) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomas F.O'Connell" Cc: PgSQL - Performance X-ASG-Orig-Subj: Re: [PERFORM] pgbench Comparison of 7.4.7 to 8.0.2 Subject: Re: pgbench Comparison of 7.4.7 to 8.0.2 References: <2784476415a96bb0912ebca41edb3d84@sitening.com> <6865.1113600214@sss.pgh.pa.us> <426C9508.8030902@sfnet.cc> <02c5560a910870da3637b6ff791e3a80@sitening.com> In-Reply-To: <02c5560a910870da3637b6ff791e3a80@sitening.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 25 Apr 2005 17:21:35.0292 (UTC) FILETIME=[3B52C7C0:01C549BB] X-Virus-Scanned: by Barracuda Spam Firewall at tecarta.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=4.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=7.0 tests=BAYES_50 X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.546 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5000] Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.726 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO, NO_DNS_FOR_FROM X-Spam-Level: X-Archive-Number: 200504/678 X-Sequence-Number: 12075 Tom, Just a quick thought: after each run/sample of pgbench, I drop the=20 database and recreate it. When I don't my results become more skewed. Steve Poe Thomas F.O'Connell wrote: > Interesting. I should've included standard deviation in my pgbench=20 > iteration patch. Maybe I'll go back and do that. > > I was seeing oscillation across the majority of iterations in the 25=20 > clients/1000 transaction runs on both database versions. > > I've got my box specs and configuration files posted. If you see=20 > anything obvious about the tuning parameters that should be tweaked,=20 > please let me know. > > Thanks for the feedback! > > -tfo > > --=20 > Thomas F. O'Connell > Co-Founder, Information Architect > Sitening, LLC > > Strategic Open Source: Open Your i=E2=84=A2 > > http://www.sitening.com/ > 110 30th Avenue North, Suite 6 > Nashville, TN 37203-6320 > 615-260-0005 > > On Apr 25, 2005, at 1:58 AM, Steve Poe wrote: > >> >There was some interesting oscillation behavior in both version of=20 >> postgres that occurred with 25 >clients and 1000 transactions at a=20 >> scaling factor of 100. This was repeatable with the distribution=20 >> >version of pgbench run iteratively from the command line. I'm not=20 >> sure how to explain this. >> >> Tom, >> >> When you see these oscillations, do they occur after so many=20 >> generated results? Some oscillation is normal, in my opinion, from=20 >> 10-15% of the performance is noise-related. >> >> The key is to tune the server that you either 1) minimize the=20 >> oscillation and/or 2)increase your overall performance above the=20 >> 10-15% baseline, and 3) find out what the mean and standard deviation=20 >> between all your results. >> >> If your results are within that range, this maybe "normal". I=20 >> follow-up with you later on what I do. >> >> Steve Poe > > >