X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 4D2CC9DD61A for ; Tue, 6 Dec 2005 19:45:04 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 34078-01 for ; Tue, 6 Dec 2005 19:45:06 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id D2A1C9DD619 for ; Tue, 6 Dec 2005 19:45:01 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id jB6Nj3IU022674; Tue, 6 Dec 2005 18:45:04 -0500 (EST) To: "Anjan Dave" cc: "Vivek Khera" , "Postgresql Performance" Subject: Re: High context switches occurring In-reply-to: <4BAFBB6B9CC46F41B2AD7D9F4BBAF785098EC2@vt-pe2550-001.vantage.vantage.com> References: <4BAFBB6B9CC46F41B2AD7D9F4BBAF785098EC2@vt-pe2550-001.vantage.vantage.com> Comments: In-reply-to "Anjan Dave" message dated "Tue, 06 Dec 2005 14:04:04 -0500" Date: Tue, 06 Dec 2005 18:45:03 -0500 Message-ID: <22673.1133912703@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.002 required=5 tests=[AWL=0.002] X-Spam-Score: 0.002 X-Spam-Level: X-Archive-Number: 200512/206 X-Sequence-Number: 16027 "Anjan Dave" writes: > -bash-3.00$ time pgbench -c 1000 -t 30 pgbench > starting vacuum...end. > transaction type: TPC-B (sort of) > scaling factor: 1 > number of clients: 1000 > number of transactions per client: 30 > number of transactions actually processed: 30000/30000 > tps = 45.871234 (including connections establishing) > tps = 46.092629 (excluding connections establishing) I can hardly think of a worse way to run pgbench :-(. These numbers are about meaningless, for two reasons: 1. You don't want number of clients (-c) much higher than scaling factor (-s in the initialization step). The number of rows in the "branches" table will equal -s, and since every transaction updates one randomly-chosen "branches" row, you will be measuring mostly row-update contention overhead if there's more concurrent transactions than there are rows. In the case -s 1, which is what you've got here, there is no actual concurrency at all --- all the transactions stack up on the single branches row. 2. Running a small number of transactions per client means that startup/shutdown transients overwhelm the steady-state data. You should probably run at least a thousand transactions per client if you want repeatable numbers. Try something like "-s 10 -c 10 -t 3000" to get numbers reflecting test conditions more like what the TPC council had in mind when they designed this benchmark. I tend to repeat such a test 3 times to see if the numbers are repeatable, and quote the middle TPS number as long as they're not too far apart. regards, tom lane