略。
某局点UIS实时告警中多次出现“仲裁主机异常”的告警,报错截图如下:
现场虽然出现 “仲裁主机异常”告警,但根据收集的日志分析,仲裁主机并无异常。即该问题仅为告警显示异常,并不影响业务以及平台正常使用。
看仲裁主机的内存使用情况,发现其cache达到14G。而正常情况下,内存cache为10G以下。、
远程查看现场的环境时,发现现场的多台主机,都出现了cache较大的情况:
主节点的内存cache达到12G。
[root@SZ-A1U20-U1 log]# free –g
total used free shared buff/cache available
Mem: 754 466 275 3 12 274
Swap: 31 0 31
备节点的内存cache达到18G。
[root@SZ-A2U20-U2 ~]# free –g
total used free shared buff/cache available
Mem: 754 183 552 4 18 557
Swap: 31 0 31
仲裁节点的内存cache达到20G。
[root@SZ-A1U23-U3 ~]# free –g
total used free shared buff/cache available
Mem: 754 402 331 3 20 338
Swap: 31 0 31
主节点的cmsd日志中有以下报错:
备节点的cmsd日志也有以下报错。:
综合以上信息,结合现场的环境,该问题定位如下:UIS超融合环境中,由于Linux操作系统自身机制,运行中读写文件时会占用内存中的cache缓存,不会立即释放,长时间运行会导致剩余的空闲内存不足。如果不及时释放缓存,会出现连续的空闲内存不足;或者由于缓存过多,导致回收过慢,使得其他进程(包括检测的进程)无法及时申请到内存,从而影响UIS告警检测。
现场之前虽然部署了drop cache脚本,但因为cron配置语法错误,该脚本并没有生效。现场后重新按照文档,部署了drop cache脚本,发现cache明显减少。
彻底解决方案:
升级至UIS E0712及之后的版本。
临时规避措施:
可以参考《ONEStor和UIS超融合产品的drop cache优化方案》进行规避,系统会定期释放内存资源,这样主机也就能及时响应双机热备的探测报文。部署完此脚本之后,建议在业务量小的时候,切换一下双机,排除主备硬件本身差异的干扰,以达到同步脚本生效的目的。
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作