In the logs previously in this thread one could see that corosync
isn't able to switch to realtime-scheduling.
This can lead to timing issues if there is load - doesn't have to
be excessive.
Corosync had issues enabling realtime-scheduling when
e.g. CPUAccounting was enabled. But that should be solved
for quite some time. Of course new issues might have come
up.
Thus I guess it would be helpful if you give us the Distribution
you are using, version of it, kernel-version, versions of
pacemaker/corosync and if you took the distro-builds or your
own builds.
Regards,
Klaus
On 5/18/21 10:18 PM, Digimer wrote:
On 2021-05-18 1:13 p.m., S Sathish S wrote:
Hi Digimer/Team,
In our product use unicast protocols and CPU load is normal while
problematic timing.
We don’t defined corosync / totem timing values using default timing
till now, Please suggest what basic we need to tune this parameter based
on cluster nodes ?
[root@node1 ~]# corosync-cmapctl | grep totem.token
runtime.config.totem.token (u32) = 19850
runtime.config.totem.token_retransmit (u32) = 4726
runtime.config.totem.token_retransmits_before_loss_const (u32) = 4
I have no experience with such large clusters, so I can't offer direct
advice. Perhaps this thread is helpful?
https://lists.clusterlabs.org/pipermail/users/2016-August/010999.html
You might also find useful advice in 'man 5 corosync.conf'.
--
Klaus Wenninger
Senior Software Engineer, EMEA ENG Base Operating Systems
Red Hat
[email protected]
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users
ClusterLabs home: https://www.clusterlabs.org/
