在Oracle RAC的環境中，如果我們發現OSW監控數據顯示包重組失敗率過高，就需要引起足夠的重視，因為這很可能會引發member kill/Node kill等重大故障，甚至在有些場景會連帶影響到所有RAC節點不可用。

一般我們會選擇調整ipfrag相關參數。除此之外，還有一種解決方案就是選擇調整私網網卡的MTU值，通常Oracle使用8k標準塊大小時，會選擇設置MTU=9000，從而減緩包重組失敗次數的增長速率，期望的理想狀態下是完全沒有包重組失敗的發生。 需要注意的是，修改MTU需要心跳交換機配合做相應的修改和適配，確保使用的交換機能夠支持巨幀，所以通常給客戶的建議會優先給出方案一，實施方案一效果不理想的情況下才會考慮方案二。

方案一：修改ipfrag相關參數

官方建議一般是修改：

net.ipv4.ipfrag_high_thresh=16Mnet.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 #分片占用內存的高閾值，默認值4194304net.ipv4.ipfrag_low_thresh = 40894464 #分片占用內存的低閾值，默認值3145728net.ipv4.ipfrag_time = 120 #分片超時時間，默認值30net.ipv4.ipfrag_secret_interval = 600 #默認值600net.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:00Errors 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: 0ORA-27301: OS failure message: Error 0ORA-27302: failure occurred at: skgxpvalpidORA-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)進行瀏覽。

總結

以上是生活随笔為你收集整理的mtu设置失败_Oracle RAC该调整网卡MTU值的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。