Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id A7010635457 for ; Wed, 8 Sep 2010 17:35:48 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 31613-02-4 for ; Wed, 8 Sep 2010 20:35:39 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 6FF0B6325EB for ; Wed, 8 Sep 2010 17:35:33 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o88KZSRO009773; Wed, 8 Sep 2010 16:35:28 -0400 (EDT) To: David Kerr cc: Greg Smith , pgsql-performance@postgresql.org Subject: Re: pgbench could not send data to client: Broken pipe In-reply-to: <20100908195654.GB49941@mr-paradox.net> References: <20100908174629.GD40339@mr-paradox.net> <8037.1283973026@sss.pgh.pa.us> <4C87E3A6.8060800@2ndquadrant.com> <20100908195654.GB49941@mr-paradox.net> Comments: In-reply-to David Kerr message dated "Wed, 08 Sep 2010 12:56:54 -0700" Date: Wed, 08 Sep 2010 16:35:28 -0400 Message-ID: <9771.1283978128@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201009/34 X-Sequence-Number: 40237 David Kerr writes: > should i be running pgbench differently? I tried increasing the # of threads > but that didn't increase the number of backend's and i'm trying to simulate > 2000 physical backend processes. The odds are good that if you did get up that high, what you'd find is pgbench itself being the bottleneck, not the server. What I'd suggest is running several copies of pgbench *on different machines*, all beating on the one database server. Collating the results will be a bit more of a PITA than if there were only one pgbench instance, but it'd be a truer picture of real-world behavior. It's probably also worth pointing out that 2000 backend processes is likely to be a loser anyhow. If you're just doing this for academic purposes, fine, but if you're trying to set up a real system for 2000 clients you almost certainly want to stick some connection pooling in there. regards, tom lane