从日志看都是心跳网络超时导致的：

可以看看是否reassemble的问题：

netstat -s | grep "packet reassembles failed"

    105794 packet reassembles failed

如果返回大于0的结果，证明存在隐患，应当建议客户进行内核参数修改。

修改方法如下：

编辑  /etc/sysctl.conf, 增加（如果已存在则是编辑）以下内容，并运行 sysctl -p

net.ipv4.ipfrag_high_thresh=16777216

net.ipv4.ipfrag_low_thresh=15728640

net.ipv4.ipfrag_time=60

如果是新安装系统，务必设上该组参数。

另外，如果网络环境相对较差（比如说跨机房），前面两个参数可以调整大一些，比如：

net.ipv4.ipfrag_high_thresh=41943040

net.ipv4.ipfrag_low_thresh=39845888

net.ipv4.ipfrag_time=60

谢谢您的回复

net.ipv4.ipfrag_high_thresh=3120000

net.ipv4.ipfrag_low_thresh=2120000

net.ipv4.ipfrag_time=60

我在系统里面部署了以上参数，而且是按照numCPU *130000公式计算的，同时low参数比high参数少1m（我的系统逻辑CPU24个）

且在两个节点分别执行netstat -s | grep "packet reassembles failed" 没有返回值，再进行重启crs，还是会引起主机重启。

昨天跟客户沟通了以后，将如下图片中的补丁进行了rollback，在补丁回退之后，故障现象就消失了，没有再发生重启crs引起主机重启的现象。我到mos上查了一下，也没找到该补丁引起的类似的issues，不知道各位专家是否了解图片中红框的补丁引起的一些问题。