Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id ED864632CFF for ; Wed, 8 Sep 2010 16:27:45 -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 36834-04 for ; Wed, 8 Sep 2010 19:27:38 +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 2115662F6AC for ; Wed, 8 Sep 2010 16:27:38 -0300 (ADT) Received: from [192.168.1.6] (static-71-179-240-8.bltmmd.fios.verizon.net [71.179.240.8]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lv8fS-1OjpZ723zW-010EuR; Wed, 08 Sep 2010 21:27:36 +0200 Message-ID: <4C87E3A6.8060800@2ndquadrant.com> Date: Wed, 08 Sep 2010 15:27:34 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Tom Lane CC: David Kerr , pgsql-performance@postgresql.org Subject: Re: pgbench could not send data to client: Broken pipe References: <20100908174629.GD40339@mr-paradox.net> <8037.1283973026@sss.pgh.pa.us> In-Reply-To: <8037.1283973026@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:PAzxGLW4CBpIdg24YSu1vXfCoURA++oCrHBn9xyi3c8 4z91jbTj3V3z1EP3/xtaNr1bWWTXQuej+pbcPjtuQMNzUz7KGG nmP34Qbk1AGe3uvz/WE9P/+N78+1rdxT/lfDhrOPraESLdjPiU mSApy8BJIt6vbhR3jIb8VtDIjsI14too+n610XEsTqLby4q7GG 1ZBEX0g5PWWDwYRDxadiRK4+nA2VuQ7CpGjAWREBuM= 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: 201009/30 X-Sequence-Number: 40233 Tom Lane wrote: > As of the 9.0 release, it's possible to run pgbench in a "multi thread" > mode, and if you forced the subprocess rather than thread model it looks > like the select() limit would be per subprocess rather than global. > So I think you could get above the FD_SETSIZE limit with a bit of > hacking if you were using 9.0's pgbench. No chance with 8.3 though. > I believe David can do this easily enough by compiling a 9.0 source code tree with the "--disable-thread-safety" option. That's the simplest way to force the pgbench client to build itself using the multi-process model, rather than the multi-threaded one. It's kind of futile to run pgbench simulating much more than a hundred or two clients before 9.0 anyway. Without multiple workers, you're likely to just run into the process switching limitations within pgbench itself rather than testing server performance usefully. I've watched the older pgbench program fail to come close to saturating an 8 core server without running into its own limitations first. You might run a 9.0 pgbench client against an 8.3 server though, if you did the whole thing starting from pgbench database initialization over again--the built-in tables like "accounts" changed to "pgbench_accounts" in 8.4. That might work, can't recall any changes that would prevent it; but as I haven't tested it yet I can't say for sure. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us