Re: max_connections reached in postgres 9.3.3
От | Merlin Moncure |
---|---|
Тема | Re: max_connections reached in postgres 9.3.3 |
Дата | |
Msg-id | CAHyXU0yKrteU8zXhZdPig8VGJs5fYYikWx_Tybbg-E=hssnq_A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: max_connections reached in postgres 9.3.3 (Erik van Zijst <erik.van.zijst@gmail.com>) |
Список | pgsql-general |
On Fri, Jun 20, 2014 at 12:58 AM, Erik van Zijst <erik.van.zijst@gmail.com> wrote: > On Thu, Jun 19, 2014 at 10:10 PM, Erik van Zijst > <erik.van.zijst@gmail.com> wrote: >> On Thu, Jun 19, 2014 at 3:57 PM, Merlin Moncure <mmoncure@gmail.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
В списке pgsql-general по дате отправления: