在Oracle RAC的环境中，如果我们发现OSW监控数据显示包重组失败率过高，就需要引起足够的重视，因为这很可能会引发member kill/Node kill等重大故障，甚至在有些场景会连带影响到所有RAC节点不可用。

一般我们会选择调整ipfrag相关参数。除此之外，还有一种解决方案就是选择调整私网网卡的MTU值，通常Oracle使用8k标准块大小时，会选择设置MTU=9000，从而减缓包重组失败次数的增长速率，期望的理想状态下是完全没有包重组失败的发生。 需要注意的是，修改MTU需要心跳交换机配合做相应的修改和适配，确保使用的交换机能够支持巨帧，所以通常给客户的建议会优先给出方案一，实施方案一效果不理想的情况下才会考虑方案二。

方案一：修改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系统的默认值进行对比：

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

这里除了修改ipfraghigh/lowthresh由默认的4M/3M改为40M/39M之外，还将ipfragtime由默认值的30修改为120，ipfragmax_dist由默认的64修改为1024。但是这个并没有找到Oracle官方的说明，只是从参数含义的角度来看应该会有所改善。这里先不作为优先修改项。

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

这个修改的官方主要依据：Recommendation for the Real Application Cluster Interconnect and Jumbo Frames (Doc ID 341788.1)

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

修改私有网卡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.

如何判定包重组失败的现象是否存在风险？

...

? 接下来内容请访问原文（https://www.modb.pro/db/28633?YYF）进行查看~

更多数据库相关内容，可访问墨天轮（https://www.modb.pro/?YYF）进行浏览。