From: ktm@rice.edu <ktm@rice.edu>
To: Scott Marlowe <scott.marlowe@gmail.com>
Cc: Евгений Селявка <evg.selyavka@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: postgresql recommendation memory
Date: Mon, 11 Nov 2013 10:26:31 -0600
Message-ID: <20131111162631.GN2790@aart.rice.edu> (raw)
In-Reply-To: <CAOR=d=1=OtQ_sUcXeqp9bY=TzMN7hM80qz5nV9E63xA9KVmxOw@mail.gmail.com>
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: ktm@rice.edu, scott.marlowe@gmail.com, evg.selyavka@gmail.com
Subject: Re: postgresql recommendation memory
In-Reply-To: <20131111162631.GN2790@aart.rice.edu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox