Date: Mon, 11 Nov 2013 10:26:31 -0600
From: "ktm@rice.edu" <ktm@rice.edu>
To: Scott Marlowe <scott.marlowe@gmail.com>
Cc: =?utf-8?B?0JXQstCz0LXQvdC40Lkg0KHQtdC70Y/QstC60LA=?=
 <evg.selyavka@gmail.com>,
 "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: postgresql recommendation memory
Message-ID: <20131111162631.GN2790@aart.rice.edu>
References: 
 <CAKPhvNYKqZhrytYh+3p9qAUtCLrSOucDgdvbJC22wqn-3sYCsA@mail.gmail.com>
 <CAOR=d=3X8W8PtzrK0HE9fuN+3i=8Kp8xd=3ECfLWijayFXf3CQ@mail.gmail.com>
 <CAKPhvNaON-vLKmsCoCjFquQ6wD0_kPRR=1v-8petpyRtykQ3Jg@mail.gmail.com>
 <CAOR=d=3MRwFUPAweGwdEgatMSVvaeEwq+V2=wYR0DGE7nN2gpQ@mail.gmail.com>
 <CAOR=d=2J68SG4HYA6DvEhT4qL8P1T9HmRsSe6SVdoQ8SOTz65w@mail.gmail.com>
 <CAOR=d=1huX86OYGoT0NNt11X2oW=mHmXQc_6=z4WZbJTdJEcAg@mail.gmail.com>
 <CAKPhvNZhD8Z8QKe6bmvY=hhT2Ejgwrmxn4zcKGjpNgZ7VCyZ=A@mail.gmail.com>
 <CAOR=d=1=OtQ_sUcXeqp9bY=TzMN7hM80qz5nV9E63xA9KVmxOw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAOR=d=1=OtQ_sUcXeqp9bY=TzMN7hM80qz5nV9E63xA9KVmxOw@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On Mon, Nov 11, 2013 at 09:14:43AM -0700, Scott Marlowe wrote:
> On Mon, Nov 11, 2013 at 1:09 AM, Евгений Селявка <evg.selyavka@gmail.com> 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance