Thanks for all the answers.
I think I need to first look into the windows connection issue (where some memory pool gets used up and then new connections cannot be made). If that does not help, upping the ram by a bit might help (at least buy some time). And looking into tuning the options that result in increased memory size to be slightly lower (does anybody know which options will lower the per connection memory usages, the only one that seems clear to me is work_mem).
But ultimately we need to rewrite the code to not keep connections open, or too not do queries that upset transaction pooling (ala pgbouncer). And we need to get that client onto Linux so that memory increases can be taken advantage of.
If there are other suggestions that would be much appreciated.
Regards,
Kobus
2009/8/10 Scott Marlowe <scott.marlowe@xxxxxxxxx>
Yeah, from what the OP stated as requirements, I'm guessing the oneOn Mon, Aug 10, 2009 at 3:16 PM, Allan Kamau<kamauallan@xxxxxxxxx> wrote:
> On Mon, Aug 10, 2009 at 7:49 PM, Vick Khera<vivek@xxxxxxxxx> wrote:
>> On Mon, Aug 10, 2009 at 9:46 AM, Bill Moran<wmoran@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx)
>> 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.
they can push back on the easiest is to get more memory and run run
Linux / BSD / OpenSolaris instead of Windows server.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
