Re: max_connections reached in postgres 9.3.3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Erik van Zijst <erik(dot)van(dot)zijst(at)gmail(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, Borislav Ivanov <bivanov(at)atlassian(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, "Vasudevan, Ramya" <ramya(dot)vasudevan(at)classmates(dot)com>
Subject: Re: max_connections reached in postgres 9.3.3
Date: 2014-06-20 14:17:16
Message-ID: 3743.1403273836@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Erik van Zijst <erik(dot)van(dot)zijst(at)gmail(dot)com> writes:
> On Thu, Jun 19, 2014 at 3:57 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> 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.

> Did that patch go in? The mailing list thread doesn't seem conclusive.

A descendant patch was applied:

http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=1a3d104475ce01326fc00601ed66ac4d658e37e5

but that's only in 9.4, not any earlier branches.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Merlin Moncure 2014-06-20 14:39:04 Re: pros/cons of using "synchronous commit=off" - AWS in particular
Previous Message Larry Prikockis 2014-06-20 13:49:27 Re: pros/cons of using "synchronous commit=off" - AWS in particular