Date: Wed, 8 Sep 2010 13:44:43 -0700
From: David Kerr <dmk@mr-paradox.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Smith <greg@2ndquadrant.com>, pgsql-performance@postgresql.org
Subject: Re: pgbench could not send data to client: Broken pipe
Message-ID: <20100908204443.GG49941@mr-paradox.net>
References: <20100908174629.GD40339@mr-paradox.net>
	<8037.1283973026@sss.pgh.pa.us> <4C87E3A6.8060800@2ndquadrant.com>
	<20100908195654.GB49941@mr-paradox.net>
	<9771.1283978128@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9771.1283978128@sss.pgh.pa.us>
User-Agent: Mutt/1.4.2.3i

On Wed, Sep 08, 2010 at 04:35:28PM -0400, Tom Lane wrote:
- David Kerr <dmk@mr-paradox.net> 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
- 

ah that's a good idea, i'll have to give that a shot.

Actually, this is real.. that's 2000 connections - connection pooled out to 
20k or so. (although i'm pushing for closer to 1000 connections).

I know that's not the ideal way to go, but it's what i've got to work with.

It IS a huge box though...

Thanks

Dave