Re: Too much clients connected to the PostgreSQL Database

Hi Kevin,

I think you are right. We need to use the connection pool for
all clients, so we can limit the number of active database connections.
We have some legacy applications that is hard to change, but we
will have to do it.

Thanks a lot,

Rodrigo

Em 10/30/2012 2:10 AM, Kevin Grittner escreveu:
> rodrigo(at)paripassu(dot)com(dot)br wrote:
>
>> 150 maxActive setting, but we have some low usage application
>> getting direct db connection(out of the pool).
> You will probably be better off with a connection pool somewhere
> between 10 and 20, as long as it is transaction-based, the client
> side has low latency to the database, and the transaction isn't
> waiting for other things (like human beings or slow connections to
> somewhere else) to get its work done.
>
>> The interesting is that the server suddently get a lot of
>> connections and reach the limit and then release them.
> That is the pattern you will tend to see if you have too many
> configured. The "thundering herd" syndrome. They charge in, drag
> down performance while they over-stress the hardware, and then move
> on.
>
>> I'm willing to change to Tomcat 7 connection pool. We are using
>> c3pO and apache ones, maybe that's a problem.
> I have seen both the Tomcat pool and DBCP work well, although I think
> the DBCP pool has more features. I don't have enough experience with
> c3p0 to comment either way. I definitely would not bother to move
> from Apache DBCP to the Tomcat pool. If I remember right I didn't
> find much worth changing from defaults in the DBCP package, but it's
> been a while. I would recommend either of those over an external
> product like pgbouncer or pgpool; those are what you go to when you
> don't have a quality connection pooler in your application software,
> IMO.
>
> The point is to configure whatever pool you use to limit the number
> of active database transactions such that the active connections are
> able to keep all available resources on the database server (cores,
> spindles, network) busy, but no more. That should improve both
> latency and throughput. There is no substitute for testing different
> sizes with your actual load against your actual hardware; any advice
> on size should be taken as the starting point for testing incremental
> changes.
>
> -Kevin

--

------------------------------------------------------------------------
*Rodrigo Pereira da Silva*
rodrigo(at)paripassu(dot)com(dot)br <mailto:rodrigo(at)paripassu(dot)com(dot)br>
http://www.paripassu.com.br
Rua Coronel Luis Caldeira, nº 67, Bloco 1, Sala 3A
88034-110 • Florianópolis • SC
Tel. (48) 3207-5755

------------------------------------------------------------------------