<div dir="ltr"><div>I am back to this question =)</div><div><br></div><div>I am still trying to understand the impact of "High CPU load detected" messages in the log.</div><div>Looking in the code I figured out that setting "load-threshold" parameter to something higher than 100% solves the problem. </div><div>And actually for 8 cores (12 with Hyper Threading) load-threshold=400% kind of works.</div><div><br></div><div>Also I noticed that this parameter may have an impact on the number of "the maximum number of jobs that can be scheduled per node". As there is a formula to limit F_CRM_THROTTLE_MAX based on F_CRM_THROTTLE_MODE.</div><div><br></div><div>Is my understanding correct that the impact of setting "load-threshold" high enough (so there is no noisy messages) will lead only to the "throttle_job_max" and nothing more.</div><div>Also, if I got it correct, than "throttle_job_max" is a number of allowed parallel actions per node in lrmd.</div><div>And a child of the lrmd is actually an RA process running some actions (monitor, start, etc).<br></div><div><br></div><div>So there is no impact on how many RA (resources) can run on a node, but how Pacemaker will operate with them in parallel (I am not sure I understand this part 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 Wed, Jun 3, 2015 at 12:17 AM, Andrew Beekhof <span dir="ltr"><<a href="mailto:andrew@beekhof.net" target="_blank">andrew@beekhof.net</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>
> On 27 May 2015, at 10:09 pm, Kostiantyn Ponomarenko <<a href="mailto:konstantin.ponomarenko@gmail.com">konstantin.ponomarenko@gmail.com</a>> wrote:<br>
><br>
> I think I wasn't precise in my questions.<br>
> So I will try to ask more precise questions.<br>
> 1. why the default value for "load-threshold" is 80%?<br>
<br>
</span>Experimentation showed it better to begin throttling before the node became saturated.<br>
<span class=""><br>
> 2. what would be the impact to the cluster in case of "load-threshold=100%”?<br>
<br>
</span>Your nodes will be busier. Will they be able to handle your load or will it result in additional recovery actions (creating more load and more failures)? Only you will know when you try.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Thank you,<br>
> Kostya<br>
><br>
> On Mon, May 25, 2015 at 4:11 PM, Kostiantyn Ponomarenko <<a href="mailto:konstantin.ponomarenko@gmail.com">konstantin.ponomarenko@gmail.com</a>> wrote:<br>
> Guys, please, if anyone can help me to understand this parameter better, I would be appreciated.<br>
><br>
><br>
> Thank you,<br>
> Kostya<br>
><br>
> On Fri, May 22, 2015 at 4:15 PM, Kostiantyn Ponomarenko <<a href="mailto:konstantin.ponomarenko@gmail.com">konstantin.ponomarenko@gmail.com</a>> wrote:<br>
> Another question - is it crmd specific to measure CPU usage by "I/O wait"?<br>
> And if I need to get the most performance of the running resources in cluster, should I set "load-threshold=95%" (or even 100%)?<br>
> Will it impact the cluster behavior in any ways?<br>
> The man page for crmd says that it will "The cluster will slow down its recovery process when the amount of system resources used (currently CPU) approaches this limit".<br>
> Does it mean there will be delays in cluster in moving resources in case a node goes down, or something else?<br>
> I just want to understand in better.<br>
><br>
> That you in advance for the help =)<br>
><br>
> P.S.: The main resource does a lot of disk I/Os.<br>
><br>
><br>
> Thank you,<br>
> Kostya<br>
><br>
> On Fri, May 22, 2015 at 3:30 PM, Kostiantyn Ponomarenko <<a href="mailto:konstantin.ponomarenko@gmail.com">konstantin.ponomarenko@gmail.com</a>> wrote:<br>
> I didn't know that.<br>
> You mentioned "as opposed to other Linuxes", but I am using Debian Linux.<br>
> Does it also measure CPU usage by I/O waits?<br>
> You are right about "I/O waits" (a screenshot of "top" is attached).<br>
> But why it shows 50% of CPU usage for a single process (that is the main one) while "I/O waits" shows a bigger number?<br>
><br>
><br>
> Thank you,<br>
> Kostya<br>
><br>
> On Fri, May 22, 2015 at 9:40 AM, Ulrich Windl <<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-regensburg.de</a>> wrote:<br>
> >>> "Ulrich Windl" <<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-regensburg.de</a>> schrieb am 22.05.2015 um<br>
> 08:36 in Nachricht <<a href="mailto:555EEA72020000A10001A71D@gwsmtp1.uni-regensburg.de">555EEA72020000A10001A71D@gwsmtp1.uni-regensburg.de</a>>:<br>
> > Hi!<br>
> ><br>
> > I Linux I/O waits are considered for load (as opposed to other Linuxes) Thus<br>
> ^^ "In" s/Linux/UNIX/<br>
><br>
> (I should have my coffee now to awake ;-) Sorry.<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Users mailing list: <a href="mailto:Users@clusterlabs.org">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>
><br>
> _______________________________________________<br>
> Users mailing list: <a href="mailto:Users@clusterlabs.org">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>
Users mailing list: <a href="mailto:Users@clusterlabs.org">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>