【HCI】corosync服务占用CPU高引起了存储网口掉线告警

更新时间：2024-09-01

所属模块集群维护虚拟存储 | 存储私网主机参数、性能

适用版本通用

本文内容包含两块内容的排障，1）corosync 服务占用 CPU 高的排查，以及2）存储网掉线排查。

这两者正好撞在一起，所以有了本文。

问题现象可能包含两个方面：

1）corosync服务跑的 DP 所在转发核上，引起高 CPU 的现象，进而会导致两者互相影响

2）corosync服务由于是集群管理的服务，很多服务有依赖，如果 CPU 高会影响主机负载情况，及集群稳定，从而影响到其他应用，比如当前的存储口掉线检测

1. 首先检查网口是否出现 down/up（查看内核日志/sf/log/today/kernel.log），发现没有

2. 然后检查告警时间段黑盒日志有没有丢包（/sf/log/blackbox/today/LOG_vs_ping.txt），发现也正常，没有丢包

3. 都正常还告警，就要确认这个告警机制是怎么判断的，查看检测日志（/sf/log/today/vs/scripts/vs_ethtool.py.log）发现是 ethtool 执行失败了

4. 手动执行 ethtool channel4，发现非常卡，等半天才会输出结果，推测是这个检测超时命令退出，返回错误，引起了误告

这种情况，可以选择其他正常主机进行对比测试，锁定是某台主机的问题。

5. top命令查看当前问题主机的系统负载情况，发现负载很高，其中 corosync CPU占用 100%

6. 进一步查看 corosync 服务进程跑在哪些 CPU 上（可用命令：ps -o psr,comm,tid -T -p `pidof corosync`）

如下图，对比正常主机，问题主机的 corosync 服务有线程跑到了 DP 转发核上（DP 转发核也可以通过该命令确认）；

因为 DP 转发核是独占的，也就是 CPU 缺省就是会跑到 100%，因此 corosync 跑到转发核上就会受影响。

corosync调度到网络服务所在核上，影响了ethtool工具的执行时间，vs的存储口掉线检测是调ethtool channelX来检测的，这个命令执行超时拿不到结果就会显示掉线，其实是没掉线，误告警。

临时解决方案：

以下命令重启 corosync 服务：

container_exec -n asv-c -c '/sf/etc/init.d/corosync restart'

永久解决方案：

解决 corosync 的调度问题，已提TD版本内修改，另外误告的检测也提TD修改（解决方案可以咨询LMT技术支持）

不影响

是

存储掉线大多数情况是网口出现down/up，或者存在丢包；

本文的误检测情况受 corosync 服务的影响，是特例；

但 corosync 服务跑的 DP 转发核上可能会有多种现象，比如影响 DP 的性能及配置下发等

{{contentObj.name||'--'}}