[ClusterLabs] Antw: Re: Antw: Re: Two node cluster goes into split brain scenario during CPU intensive tasks

Ulrich Windl Ulrich.Windl at rz.uni-regensburg.de
Mon Jul 1 09:24:28 EDT 2019

>>> Jan Pokorný <jpokorny at redhat.com> schrieb am 01.07.2019 um 14:42 in
<20190701124215.GN31192 at redhat.com>:
> On 01/07/19 13:26 +0200, Ulrich Windl wrote:
>>>>> Jan Pokorný <jpokorny at redhat.com> schrieb am 27.06.2019 um 12:02
>>>>> in Nachricht <20190627100209.GF31192 at redhat.com>:
>>> On 25/06/19 12:20 ‑0500, Ken Gaillot wrote:
>>>> On Tue, 2019‑06‑25 at 11:06 +0000, Somanath Jeeva wrote:
>>>> Addressing the root cause, I'd first make sure corosync is running at
>>>> real‑time priority (I forget the ps option, hopefully someone else can
>>>> chime in).
>>> In a standard Linux environment, I find this ultimately convenient:
>>>   # chrt ‑p $(pidof corosync)
>>>   pid 6789's current scheduling policy: SCHED_RR
>>>   pid 6789's current scheduling priority: 99
>> To me this is like pushing a car that already has a running engine! If
>> corosync does crazy things, this will make things worse (i.e. enhance
>> crazyness).
> Note that said invocation is read-only fetch of the process
> characteristic.  So not sure about your parable, it shall
> rather be compared to not paying full attention to driving

Ah, sorry, the heat (here): I was not paying attention, thinking the command
was used to set the real-time scheduling parameters, while in fact they had
been set already. Apologies!

> itself for a bit when checking the speedometer (the check
> alone won't presumably run with such an ultimate scheduling
> priority, so the interferences shall be fairly minimal, just
> as with `ps` or whatever programmatic fetch of such data).
>>> (requires util‑linux, procps‑ng)
> -- 
> Jan (Poki)

More information about the Users mailing list