2023年12月6日发(作者：)

关于OracleRAC调整网卡MTU值的问题

墨墨导读：在Oracle RAC的环境中，如果我们发现OSW监控数据显示包重组失败率过高，就需要引起足够的重视，因

为这很可能会引发member kill/Node kill等重大故障，甚至在有些场景会连带影响到所有RAC节点不可用。

一般我们会选择调整ipfrag相关参数。除此之外，还有一种解决方案就是选择调整私网网卡的MTU值，通常Oracle使用

8k标准块大小时，会选择设置MTU=9000，从而减缓包重组失败次数的增长速率，期望的理想状态下是完全没有包重组

失败的发生。

需要注意的是，修改MTU需要心跳交换机配合做相应的修改和适配，确保使用的交换机能够支持巨帧，所以通常给客户

的建议会优先给出方案一，实施方案一效果不理想的情况下才会考虑方案二。

方案一：修改ipfrag相关参数

官方建议一般是修改：

•

•

_high_thresh=16M _low_thresh=15M

另外，如果实际业务量比较大，可以考虑进一步增大这两个值，比如修改为32M/31M甚至64M/63M，一般high和low相

差1M即可。

结合公司专家们的实战经验，对ipfrag系列参数给了一个参考，我这里结合网上的资料和RHEL7系统的默认值进行对

比：

•

•

•

•

•

_high_thresh = 41943040 #分片占用内存的高阈值，默认值4194304 _low_thresh =

40894464 #分片占用内存的低阈值，默认值3145728 _time = 120 #分片超时时间，默认值30

_secret_interval = 600 #默认值600 _max_dist = 1024 #分片有效的最长间隔距离，默认值

64

这里除了修改ipfrag_high/low_thresh由默认的4M/3M改为40M/39M之外，还将ipfrag_time由默认值的30修改为

120，ipfrag_max_dist由默认的64修改为1024。但是这个并没有找到Oracle官方的说明，只是从参数含义的角度来看应

该会有所改善。这里先不作为优先修改项。

方案二：使用巨帧，调整MTU值

当方案一实施后效果不明显时，则考虑调整MTU值，这里选择设置MTU=9000：

修改私有网卡MTU为9000:

•

•

•

•

•

•

•

•

ifconfig<网卡名称> mtu 9000 查看MTU是否更改成功： ifconfig<网卡名称> 修改私有网卡配置文件，添加MTU= 9000的

配置，以确保主机重启后MTU=9000不变：vi/etc/sysconfig/network-s/ifcfg-<网卡名称>配置文件末尾新添加一行MTU=配置，以确保主机重启后MTU=9000不变：vi/etc/sysconfig/network-s/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:00Errors in file

/oracle/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_lmon_:ORA-27300: OS system dependent

operation:config_check failed withstatus: 0ORA -27301: OS failuremessage: Error0ORA -27302: failureoccurred at:

skgxpvalpid ORA -27303: additional information: Remote port MTU does notmatchlocalMTU. [ local: 9000, remote:

1500] ( 169.254.1.60) 如何判定包重组失败的现象是否存在风险？上面讲了半天的包重组失败，那该如何判定当前系统

包重组失败是否存在风险？当然理想环境下，不应该出现包重组失败的现象，但如果环境不够理想，那有没有一个参考

值，多长时间内包重组失败超过多少次就会有问题？或者有其他的判定标准？ 目前了解到的是对于Oracle RAC，对包

重组失败速率并没有一个统一的标准来定义正常/不正常的临界值： 为此客户也开过SR求证，O原厂回复也是说没有一

定的标准，只是基于数据库性能和稳定性方面建议是减少内网包重组现象。 我也咨询了专家罗海雄老师，认为一般30s

内包重组失败超过5个就需要给予一定的关注，持续观察是否存在风险，并给出下面的awk命令来辅助观察osw的netstat

数据： 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脚本不再可用

了，观察新的数据格式，改写脚本如下： awk'/zzz/{d= $4"-" $5}/IpReasmFails/{curr= $2;diff=curr-prev;if(diff>5)print

d,diff,prev,curr;prev=curr}' *.dat最后要提一下的是，当出现这类问题时，还要配合检查私网本身是否存在问题，比如：

网卡、网线、交换机等，都要确保状态正常，排除硬件本身的问题。