[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-performance
Subject:    Re: [PERFORM] Connection pooling - Number of connections
From:       Brett Wooldridge <brett.wooldridge () gmail ! com>
Date:       2014-03-30 3:41:30
Message-ID: DF286FBF-D1F5-4A10-88AD-EDD5D2AFAABD () gmail ! com
[Download RAW message or body]

Sent from my iPhone
> On Mar 27, 2014, at 9:35 AM, Josh Berkus <josh@agliodbs.com> wrote:
> 
> > On 03/24/2014 06:27 AM, Brett Wooldridge wrote:
> > This was one of the reasons I was proposing the fixed pool design.  In my
> > experience, even in pools that maintain a minimum number of idle
> > connections, responding to spike demands is problematic.  If you have a
> > pool with say 30 max. connections, and a 10 minimum idle connection goal, a
> > sudden spike demand for 20 connections means the pool can satisfy 10
> > instantly but then is left to [try to] establish 10 connections before the
> > application's connectionTimeout (read acquisition timeout from the pool) is
> > reached.  This in turn generates a spike demand on the database slowing
> > down not only the connection establishments themselves but also slowing
> > down the completion of transactions that might actually return connections
> > to the pool.
> 
> Now, if your peak is 100 connections and your median is 50, this doesn't
> signify.  But I know more than a few workloads where the peak is 1000
> and the median is 25, and in that case you want to drop the idle
> connections gradually.

In the end we've gone with a maxPoolSize + minIdle model where the default is that \
they are equal (fixed pool).

Though I won't dispute that such workloads (1000 active connections) exist, in that \
someone created it, I would love to hear their justification. Unless they have >128 \
CPU cores and solid state storage they are basically spinning their wheels.

> That also means that even if the pool is a fixed size, you want to
> rotate in and out the actual sessions, so that they don't hang onto
> maximum virtual memory indefinitely.

We do this, there is a maxLifeTime setting to rotate out connections.

-Brett



-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


[prev in list] [next in list] [prev in thread] [next in thread]