On Wed, Sep 08, 2010 at 04:35:28PM -0400, Tom Lane wrote: - David Kerr <dmk@xxxxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
