RAC 心跳异常（ipReamsfails）的处理记录和分析

Posted 2022-07-14 wx58c6cc2e19ab5

::: hljs-left

环境信息

Oracle 19.12
Oracle Linux 7.9

一：真实生产环境现象

轻度影响时：

1. 用户反馈数据库连接失败、短暂持续几分钟后恢复正常
2. crs日志有节点通信异常信息
3. OSWatcher ipReamsfails 增长

   重度影响时：

4. 用户反馈数据库连接失败、生产业务停机
5. crs节点踢出，操作系统重启
6. 切换到dg库，仍然发生crs节点踢出，操作系统重启
7. 停止数据库2节点。单实例数据库运行正常，观察两周无任何报错。
8. OSWatcher ipReamsfails 大量增长

二：测试前，生产环境采取的动作：

1. 修改操作系统内核参数从4M、3M增加到，15M、16M（官方文档ID：2008933.1）问题依旧
2. 修改私网连接方式，采用网线直连，问题依旧

三：开始压力测试（采用swingbench）的结果

• 测试场景二：

• 测试场景三：

• 测试场景四：

四：测试总结

1. 测试过程中压力是实际生产的10倍以上。
2. 没有发现数据库节点驱逐现象。
3. CRS日志有节点通信异常信息。
4. OSWatcher 日志中有发现ipReamsfails增长。

五：最终解决

1. 调整心跳交换机配置启用巨帧（Jumbo Frame）
2. 调整心跳网卡 MTU大小=9000

六：后续的测试计划

1. 升级操作系统内核测试
2. 从Oracle Linux 切换为Redhat Linux 测试
3. 新服务器测试
4. 有条件的话，后续会补充不同系统和硬件平台的测试情况。没条件就鸽了。

七：问题分析和总结

• 什么情况下网络数据包会被放入ipfrag 缓存中，且造成ipReamsFails 值增长？

在默认情况下(MTU 1500字节)在业务网和心跳网的数据传输都会进行拆包和组包，此时会数据包会被放入ipfrag 缓存中。

数据库读取操作系统网络IO，操作系统从ipfrag_thresh 的缓存中读取数据包，进行重组，将包组装成SDU块 或 DB_BLOCK块。

当操作系统从ipfrag_thresh缓存中读取数据包进行包重组的效率低于ipfrag_thresh缓存增长的效率时，ipfrag_thresh 缓存会逐渐增加，当达到缓存最大值时，新增数据包丢弃，数据包接收不完整，包重组失败。报错：IP reassembles failed ，IpReamsfails 值增长。

• 如何避免此类现象？

• 其他原因？

附：官方文档和参考描述

1. Troubleshooting gc block lost and Poor Network Performance in a RAC Environment (Doc ID 563566.1)
   参照原厂文档调整了心跳网卡直连方式、升级网卡驱动。
2. IPC Send timeout/node eviction etc with high packet reassembles failure (Doc ID 2008933.1)
   参照原厂文档调整了ipfrag_thresh。
3. Recommendation for the Real Application Cluster Interconnect and Jumbo Frames (Doc ID 341788.1)
   参照原厂文档调整了MTU大小9000，调整后问题没有复现。

遇到过该问题的可以一起讨论，目前还有未覆盖到的盲点，比如测试没有复现出RAC节点驱逐、只调整了私网心跳，没有涉及跟APP之间业务流量的调整。

:::