在Oracle RAC的环境中，若是咱们发现OSW监控数据显示包重组失败率太高，就须要引发足够的重视，由于这极可能会引起member kill/Node kill等重大故障，甚至在有些场景会连带影响到全部RAC节点不可用。node
通常咱们会选择调整ipfrag相关参数。除此以外，还有一种解决方案就是选择调整私网网卡的MTU值，一般Oracle使用8k标准块大小时，会选择设置MTU=9000，从而减缓包重组失败次数的增加速率，指望的理想状态下是彻底没有包重组失败的发生。
须要注意的是，修改MTU须要心跳交换机配合作相应的修改和适配，确保使用的交换机可以支持巨帧，因此一般给客户的建议会优先给出方案一，实施方案一效果不理想的状况下才会考虑方案二。
shell
方案一：修改ipfrag相关参数
官方建议通常是修改：数据库
net.ipv4.ipfrag_high_thresh=16M net.ipv4.ipfrag_low_thresh=15M
这个修改的官方主要依据是 RHEL 6.6: IPC Send timeout/node eviction etc with high packet reassembles failure (Doc ID 2008933.1) ，虽然文档给出的是RHEL6.6，但实际经验是在6.6之后的版本也建议修改，在不少真实案例中，不止局限于6.6这个版本。
另外，若是实际业务量比较大，能够考虑进一步增大这两个值，好比修改成32M/31M甚至64M/63M，通常high和low相差1M便可。
结合公司专家们的实战经验，对ipfrag系列参数给了一个参考，我这里结合网上的资料和RHEL7系统的默认值进行对比：
oracle
net.ipv4.ipfrag_high_thresh = 41943040 #分片占用内存的高阈值，默认值4194304 net.ipv4.ipfrag_low_thresh = 40894464 #分片占用内存的低阈值，默认值3145728 net.ipv4.ipfrag_time = 120 #分片超时时间，默认值30 net.ipv4.ipfrag_secret_interval = 600 #默认值600 net.ipv4.ipfrag_max_dist = 1024 #分片有效的最长间隔距离，默认值64
这里除了修改ipfrag_high/low_thresh由默认的4M/3M改成40M/39M以外，还将ipfrag_time由默认值的30修改成120，ipfrag_max_dist由默认的64修改成1024。可是这个并无找到Oracle官方的说明，只是从参数含义的角度来看应该会有所改善。这里先不做为优先修改项。app
方案二：使用巨帧，调整MTU值
这个修改的官方主要依据：Recommendation for the Real Application Cluster Interconnect and Jumbo Frames (Doc ID 341788.1)
当方案一实施后效果不明显时，则考虑调整MTU值，这里选择设置MTU=900：
性能
修改私有网卡MTU为9000: ifconfig <网卡名称> mtu 9000 查看MTU是否更改为功： ifconfig <网卡名称> 修改私有网卡配置文件，添加MTU=9000的配置，以确保主机重启后MTU=9000不变： vi /etc/sysconfig/network-scripts/ifcfg-<网卡名称> 配置文件末尾新添加一行MTU=9000的配置： MTU=9000
在实际测试验证中发现，节点1主机重启后没法启动ASM实例，alert明确报错MTU远端是1500，即便远端ifconfig临时修改MTU=9000也不行，这个结果仍是很意外的，以前没想到这个mtu的修改竟然不能实现彻底滚动，也就是说停机是不可避免的（ifconfig能够动态修改mtu，可是若是rac想用上mtu=9000的话须要重启）。测试
--节点1主机重启后没法启动ASM实例，alert明确报错MTU远端是1500，即便远端已经临时修改过MTU=9000： 2020-07-03T17:15:52.602414+08:00 Errors in file /oracle/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_lmon_12878.trc: ORA-27300: OS system dependent operation:config_check failed with status: 0 ORA-27301: OS failure message: Error 0 ORA-27302: failure occurred at: skgxpvalpid ORA-27303: additional information: Remote port MTU does not match local MTU. [local: 9000, remote: 1500] (169.254.1.60)
在MOS 947223.1文档中也有说明：After correct MTU issue, a node reboot is required to bring up CRS stack and ASM instance for 11.2 release.ui
如何断定包重组失败的现象是否存在风险？
上面讲了半天的包重组失败，那该如何断定当前系统包重组失败是否存在风险？固然理想环境下，不该该出现包重组失败的现象，但若是环境不够理想，那有没有一个参考值，多长时间内包重组失败超过多少次就会有问题？或者有其余的断定标准？
目前了解到的是对于Oracle RAC，对包重组失败速率并无一个统一的标准来定义正常/不正常的临界值：
为此客户也开过SR求证，O原厂回复也是说没有必定的标准，只是基于数据库性能和稳定性方面建议是减小内网包重组现象。
我也咨询了专家罗海雄老师，认为通常30s内包重组失败超过5个就须要给予必定的关注，持续观察是否存在风险，并给出下面的awk命令来辅助观察osw的netstat数据：
spa
awk '/zzz/{d=$4"-"$5}/packet reassembles failed/{curr=$1;diff=curr-prev;if(diff>5)print d,diff,prev,curr;prev=curr}' *.dat
根据上述语句分析了10余套系统，惟有出现过问题的这套环境依然存在风险，下一步计划修改MTU值后再观察。
此外，O原厂建议增长OSW私网的监控，但须要注意增长这个监控后，不止多了oswprvtnet等监控数据，以前netstat监控数据的格式也会发生变化，会详细列出每一个网卡的监控信息，但格式变化后的连带影响就是上面awk脚本再也不可用了。
最后要提一下的是，当出现这类问题时，还要配合检查私网自己是否存在问题，好比：网卡、网线、交换机等，都要确保状态正常，排除硬件自己的问题。
code