Re: max_connections reached in postgres 9.3.3

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Erik van Zijst <erik(dot)van(dot)zijst(at)gmail(dot)com>
Cc: "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 13:09:39
Message-ID: CAHyXU0yKrteU8zXhZdPig8VGJs5fYYikWx_Tybbg-E=hssnq_A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Jun 20, 2014 at 12:58 AM, Erik van Zijst
<erik(dot)van(dot)zijst(at)gmail(dot)com> wrote:
> On Thu, Jun 19, 2014 at 10:10 PM, Erik van Zijst
> <erik(dot)van(dot)zijst(at)gmail(dot)com> wrote:
>> 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.
>
> Also, that thread talks about slave databases (we're seeing these
> issues exclusively on our master). Is that RecoveryMightBeInProgress
> code applicable to masters, too?

hm -- no. However, it shows how important it is to grab a performance
profile in cases of suspected contention.

merlin

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Abdul Sayeed 2014-06-20 13:14:05 Re: Postgresql not getting assigned memory
Previous Message enrique.perez 2014-06-20 13:04:57 pgAgent