> Not really enough info to debug... And I don't think I encountered this
> myself.
Is there something more I can do to gather more information when this happens?
I'm not very familiar with strace, just ran it on the PID and saw the screen
fill up with sched_yield() lines... This happens acro
On a couple clusters that have been running for a little while (without
fencing), I'm seeing runaway server.rb processes using 100% of a single CPU
core each.
When I look at ps, I can see that these have something to do with pcsd:
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME
, copy in the recovery.conf, and `pcs cluster start` for each
standby node needing rebuilt?
> On May 13, 2018, at 5:58 AM, Jehan-Guillaume de Rorthais
> wrote:
>
> This message originated outside of DISH and was sent by: j...@dalibo.com
>
> On Fri, 11 May 2018 16:25:18 +00
I'm using PAF and my corosync log ends up filled with messages like this (about
3 times per minute for each standby node):
pgsqlms(postgresql-10-main)[26822]: 2018/05/11_06:47:08 INFO: Forbidding
promotion on "d-gp2-dbp63-1" in state "startup"
pgsqlms(postgresql-10-main)[26822]: 2018/05
I'm using PAF and my corosync log ends up filled with messages like this (about
3 times per minute for each standby node):
pgsqlms(postgresql-10-main)[26822]: 2018/05/11_06:47:08 INFO: Forbidding
promotion on "d-gp2-dbp63-1" in state "startup"
pgsqlms(postgresql-10-main)[26822]: 2018/05
