<div dir="ltr">Jan, thank you for the help.<div>I assume that my understanding of what was happening is correct.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Thank you,<div>Kostia</div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Feb 19, 2016 at 12:11 PM, Jan Friesse <span dir="ltr"><<a href="mailto:jfriesse@redhat.com" target="_blank">jfriesse@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jan, thank you for the answer. I still have few questions.<br>
<br>
Also, FYI, this happened on a cluster with just one node.<br>
The cluster is designed to be a two-node cluster, with possibility to work<br>
even with only one node.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and if corosync was not scheduled for more than token timeout "Process<br>
</blockquote></blockquote>
pause detected for ..." message is displayed and new membership is formed.<br>
That meant other nodes will call STONITH to fence that node. Right?<br>
Although, it didn't happen that way, because there was no the other<br>
"online" node in the cluster.<br>
And because I didn't configure my fencing device to accept node-list, it<br>
was called by the cluster.<br>
And the call was successful because of the logic - the other node was not<br>
connected to the STONITH physical device, equals to a "successful STONITH".<br>
And then that Pacemaker's logic worked out to to shut down itself ("crit:"<br>
message in the log).<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is really no help. It's best to make sure corosync is scheduled<br>
</blockquote></blockquote>
regularly.<br>
I may sound silly, but how can I do it?<br>
</blockquote>
<br></span>
It's actually very hard to say. Pauses like 30 sec is really unusual and shouldn't happen (specially with RT scheduling). It is usually happening on VM where host is overcommitted. I don't think it's your case. Another problem may be thrashing (what in theory may be the case because of "Out of memory: Kill process 8674 ..." message).<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I did:<br>
# grep -n --color "Process pause detected for\|Corosync main process was<br>
not scheduled for\|invoked oom-killer\|kernel: Out of memory: Kill<br>
process\|kernel: Killed process\|RA:\|error:\|fence\|STONITH"<br>
B5-2U-205-LS.log >B5-2U-205-LS.log.cluster_excerpt<br>
<br>
and attached it to the letter.<br>
<br>
<br>
I see complete disaster in the syslog.<br>
Correct me if I am wrong, but here I will try to analyze what happened to<br>
the cluster:<br>
<br>
At some time, when the system has already been working under the really<br>
high load for about 16 hours, Corosync started to report that "Corosync<br>
main process was not scheduled for ...".<br>
Which means that Corosync wasn't scheduled by the OS often enough so it<br>
couldn't detect membership changes (token timeout).<br>
Then, after a few such messages which appeared almost in a row, monitor<br>
operation of few resources failed.<br>
Question: in the log, entries from Resource Agent is shown first, then<br>
"lrmd" reports a timeout problem, like this:<br>
<br>
Jan 29 07:00:19 B5-2U-205-LS diskHelper(sm0dh)[18835]: WARNING: RA:<br>
[monitor] : got rc=1<br>
Jan 29 07:00:32 B5-2U-205-LS lrmd[3012]: notice: operation_finished:<br>
sm0dh_monitor_30000:18803:stderr [ Failed to get properties: Connection<br>
timed out ]<br>
<br>
Does it mean that the monitor failed because of timeout?<br>
<br>
Two minutes later Corosync started to report another message "Process pause<br>
detected for ..."<br>
Which means that Corosync was not scheduled for more than a token timeout.<br>
Then five minutes later I heave this line in the log:<br>
<br>
Jan 29 07:05:54 B5-2U-205-LS kernel: stonithd invoked oom-killer:<br>
gfp_mask=0x201da, order=0, oom_score_adj=0<br>
<br>
Which I assume states for "stonithd tried to allocate some memory, and<br>
kernel decided to run oom-killer, because there was no enough available<br>
memory". I am right here?<br>
Why stonithd activated that time?<br>
Was it because of "Process pause detected for ..." Corosync's message?<br>
What stonithd actually aimed to do?<br>
<br>
Then oom-killer kills one of heavy processes.<br>
Then systemd-journal requests memory (?) and another one heavy resource<br>
goes down, killed by oom-killer.<br>
<br>
Both killed resources was under Pacemaker's control.<br>
Other processes managed by Pacemaker report monitor timeout (?).<br>
Then one of them times out on "stop" operation and so Pacemaker requests a<br>
node to be STONITHed.<br>
There is only one node in the cluster and the only running resource is not<br>
designed (properly - don't have "node-list") to kill the node on which it<br>
runs.<br>
And because there is no another guy physically connected to the fencing<br>
device - STONITH reports success.<br>
Pacemaker's internal check works out (thank you guys!) and Pacemaker shuts<br>
down itself.<br>
<br>
<br>
Please, correct me if I am wrong in this log analyzing. I just want to<br>
level up in understanding what is happening here.<br>
As a general question, is this all happened because of:<br>
<br>
For some reasons Corosync started to experience a lack of processor time<br>
(scheduling).<br>
That is why monitor operations started to time out.<br>
Than after "Process pause detected for ..." message I assume the node<br>
should be STONITHed by the other node, but there is no another node, so<br>
what should happen in that case?<br>
Than for some reasons "stonithd" triggered "oom-killer", which killed one<br>
of the managed resources. Why?<br>
Monitor function time out for all resources continuously.<br>
Eventually "stop" function times out for one of the resources, that is why<br>
Pacemaker eventually shuts down.<br>
<br>
Please correct me in case I am wrong anywhere in my assumptions.<br>
<br>
Thank you for spending your precious time reading all this =)<br>
Hope for some help here =)<br>
<br>
<br>
Thank you,<br>
Kostia<br>
<br>
On Wed, Feb 17, 2016 at 6:47 PM, Jan Friesse <<a href="mailto:jfriesse@redhat.com" target="_blank">jfriesse@redhat.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Kostiantyn Ponomarenko napsal(a):<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thank you for the suggestion.<br>
The OS is Debian 8. All Packages are build by myself.<br>
libqb-0.17.2<br>
corosync-2.3.5<br>
cluster-glue-1.0.12<br>
pacemaker-1.1.13<br>
<br>
It is really important for me to understand what is happening with the<br>
cluster under the high load.<br>
<br>
</blockquote>
<br>
For Corosync it's really simple. Corosync has to be scheduled by OS<br>
regularly (more often than it's current token timeout) to be able to detect<br>
membership changes and send/receive messages (cpg). If it's not scheduled,<br>
membership is not up to date and eventually when it's finally scheduled, it<br>
logs "process was not scheduled for ... ms" message (warning for user) and<br>
if corosync was not scheduled for more than token timeout "Process pause<br>
detected for ..." message is displayed and new membership is formed. Other<br>
nodes (if scheduled regularly) sees non regularly scheduled node as dead.<br>
<br>
So I would appreciate any help here =)<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br>
There is really no help. It's best to make sure corosync is scheduled<br>
regularly.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thank you,<br>
Kostia<br>
<br>
On Wed, Feb 17, 2016 at 5:02 PM, Greg Woods <<a href="mailto:woods@ucar.edu" target="_blank">woods@ucar.edu</a>> wrote:<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Feb 17, 2016 at 3:30 AM, Kostiantyn Ponomarenko <<br>
<a href="mailto:konstantin.ponomarenko@gmail.com" target="_blank">konstantin.ponomarenko@gmail.com</a>> wrote:<br>
<br>
Jan 29 07:00:43 B5-2U-205-LS corosync[2742]: [MAIN  ] Corosync main<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
process was not scheduled for 12483.7363 ms (threshold is 800.0000 ms).<br>
Consider token timeout increase.<br>
<br>
</blockquote>
<br>
<br>
I was having this problem as well. You don't say which version of<br>
corosync<br>
you are running or on what OS, but on CentOS 7, there is an available<br>
<br>
</blockquote>
<br>
</blockquote>
This update sets round robin realtime scheduling for corosync by default.<br>
Same can be achieved without update by editing /etc/sysconfig/corosync and<br>
changing COROSYNC_OPTIONS line to something like COROSYNC_OPTIONS="-r"<br>
<br>
Regards,<br>
   Honza<br>
<br>
<br>
update that looks like it might address this (it has to do with<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
scheduling). We haven't gotten around to actually applying it yet because<br>
it will require some down time on production services (we do have a few<br>
node-locked VMs in our cluster), and it only happens when the system is<br>
under very high load, so I can't say for sure the update will fix the<br>
issue, but it might be worth looking into.<br>
<br>
--Greg<br>
<br>
<br>
_______________________________________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
<br>
<br>
<br>
</blockquote>
<br>
<br>
_______________________________________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
<br>
<br>
</blockquote>
<br>
_______________________________________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
<br>
</blockquote>
<br>
<br>
<br>
_______________________________________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
<br>
</blockquote>
<br>
<br>
_______________________________________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
</div></div></blockquote></div><br></div>