Re: Postgres memory question

On Mon, Aug 10, 2009 at 3:16 PM, Allan Kamau<kamauallan(at)gmail(dot)com> wrote:
> On Mon, Aug 10, 2009 at 7:49 PM, Vick Khera<vivek(at)khera(dot)org> wrote:
>> On Mon, Aug 10, 2009 at 9:46 AM, Bill Moran<wmoran(at)potentialtech(dot)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(at)postgresql(dot)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.

Yeah, from what the OP stated as requirements, I'm guessing the one
they can push back on the easiest is to get more memory and run run
Linux / BSD / OpenSolaris instead of Windows server.