Re: max_connections reached in postgres 9.3.3

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Borislav Ivanov <bivanov(at)atlassian(dot)com>
Cc: Kevin Grittner <kgrittn(at)ymail(dot)com>, "Vasudevan, Ramya" <ramya(dot)vasudevan(at)classmates(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: max_connections reached in postgres 9.3.3
Date: 2014-06-19 22:57:22
Message-ID: CAHyXU0zFR56+HuPZYq3MtCczgDxyR9+Sm-CY3usn=ZV1RWqg9A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Jun 19, 2014 at 5:12 PM, Borislav Ivanov <bivanov(at)atlassian(dot)com> wrote:
> However, most people on our team think that the number of connections is
> purely a symptom of the actual problem. We would love to be wrong about
> this. But for now we feel the high number of connections contributes for
> preserving the problem but it's not actually triggering the problem.

This is entirely correct. pgbouncer does not preventing database load
but about limiting damage when it occurs. This generally necessary in
environments where application servers keep piling on connections when
the database is not clearing queries fast enough.

In your case user% is dominating system load. Along with the high cs
this is really suggesting spinlock contention. A 'perf top' is
essential for identifying the culprit. It's very possible that 9.4
will fix your problem...see:
http://postgresql.1045698.n5.nabble.com/Cpu-usage-100-on-slave-s-lock-problem-td5768655.html.
There was some poorly optimized code in the wal replay.

merlin

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Vasudevan, Ramya 2014-06-19 23:14:05 Re: max_connections reached in postgres 9.3.3
Previous Message Borislav Ivanov 2014-06-19 22:47:57 Re: Best backup strategy for production systems