On Mon, Nov 11, 2013 at 09:14:43AM -0700, Scott Marlowe wrote: > On Mon, Nov 11, 2013 at 1:09 AM, Евгений Селявка <evg.selyavka@xxxxxxxxx> wrote: > > Scott hi, i calculate all of my jdbc pool size. Maximum is 300 connections > > from components wich use jdbc. I don't think that this is a good idea use > > pgbouncer, because our application using spring framework which using jdbc > > and prepared statement. I try to talk with our developer about disabling > > prepared statement in this framework, they don't want do this. Thats why i > > will try to upgrade HW and buy CPU with more core as you say based on > > formula 3-4xcore. But most of this connection is idle. This is a web based > > app not a datawarehouse, thats why all this connection is lightwear. > > > > About my db freeze i set this kernel parameter: > > echo 1048576 > /proc/sys/vm/min_free_kbytes > > echo 80 > /proc/sys/vm/vfs_cache_pressure > > > > And my freeze intervals is steel smaller. I try to dig deeper. > > well you can hopefully reduce connections from jdbc pooling then. The > fact that the connections are idle is good. > > The problem you run into is what happens when things go into > "overload" I.e. when the db server starts to slow down, more of those > idle connections become not idle. If all 300 are then waiting on the > db server, it will slow to a crawl and eventually fall over. > +1 I would definitely encourage the use of pgbouncer to map the 300 connections to a saner number that your DB can actually handle. We had a similar problem and very, very occasionally the server would "lockup". Once we put the resource management pooler in place, performance has been the same best-case and much, much better worse-case and NO lockups. Regards, Ken -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
