On Mon, Aug 10, 2009 at 7:49 PM, Vick Khera<vivek@khera.org> wrote:
> On Mon, Aug 10, 2009 at 9:46 AM, Bill Moran<wmoran@potentialtech.com> wrote:
>> We have servers using about 200 connections on average ... it climbs up
>> to 300+ during busy use. I've seen it peak as high as 450, and we've seen
>> no performance issues.
>>
>> This is a quad core with 4G of RAM. Of course the OS isn't windows, it's
>> 64 bit FreeBSD.
>
> I too run 64bit FreeBSD 7.2. However in my primary use case, anything
> short of 20GB of RAM makes the application very unresponsive when many
> customers are online. We usually don't have more than about 45 to 50
> connections simultaneously. My general-use Pg server has 4GB and that
> is more than adequate for the miscellaneous uses of blogs, ad servers,
> and drupal installations.
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
Hi Kobus,
My simple (perhaps wrong) understanding of how DB connection pooling
works is that no active connection(s) can be shared. The connection
pool manager may however assign a free connection from the connection
pool to service a connection request, and a connection is usually
declared as free when the application having the active connection
closes it (or returns it to the pool in a connection pool specific
manner).
If this is correct, having an application request for a connection at
the start of a session then holding on to it for the duration of the
session may yield at least as many connections to the DB as there are
sessions. It may then be advisable to (re)write the application to
open (request for a connection from the pool) and close (return a
connection to the pool) DB connections for each logical data
transaction (or group of closely associated transactions). Since in
your case a code rewrite seems unfavourable (due to time pressure) the
DB connection pooling option may not be viable as you may have
noticed.
Allan.
