在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