Skip site navigation (1) Skip section navigation (2)

Re: pgbench could not send data to client: Broken pipe

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "David Kerr" <dmk(at)mr-paradox(dot)net>
Cc: "Greg Smith" <greg(at)2ndquadrant(dot)com>, <pgsql-performance(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: pgbench could not send data to client: Broken pipe
Date: 2010-09-08 20:56:24
Message-ID: 4C87B22802000025000353B7@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-performance
David Kerr <dmk(at)mr-paradox(dot)net> wrote:
 
> 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...
 
FWIW, my benchmarks (and I've had a couple people tell me this is
consistent with what they've seen) show best throughput and best
response time when the connection pool is sized such that the number
of active PostgreSQL connections is limited to about twice the
number of CPU cores plus the number of effective spindles.  Either
you've got one heck of a machine, or your "sweet spot" for the
connection pool will be well under 1000 connections.
 
It is important that your connection pool queues requests when
things are maxed out, and quickly submit a new request when
completion brings the number of busy connections below the maximum.
 
-Kevin

In response to

Responses

pgsql-performance by date

Next:From: David KerrDate: 2010-09-08 21:20:56
Subject: Re: pgbench could not send data to client: Broken pipe
Previous:From: David KerrDate: 2010-09-08 20:44:43
Subject: Re: pgbench could not send data to client: Broken pipe

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group