RAC 環境中 gc block lost 和私網通訊效能問題的診斷 (文件 ID 1674865.1)

文件內容

適用於:

症狀

概要：

在Oracle的RAC環境中，資料庫會收集global cache 的工作負載統計資訊，並把這些資訊透過STATSPACK, AWRs 和 GRID CONTROL等工具呈報。對於每個節點，以及叢集彙總統計資訊中的global cache資料塊丟失的統計資訊("gc cr block lost" 和/或 "gc current block lost") 代表了私網通訊的包處理效率低或者包的處理存在異常。這些資訊是需要定期進行監控和評估來保證私網之間的global cache和 Enqueue服務（gcs/ges）以及叢集之間的正常通訊。任何塊丟失的資訊都說明私網在對資料包的處理過程中是存在異常情況並且需要進行調查。

資料庫絕大部分的 “global cache lost blocks”的問題都可以直接聯絡到私網的故障和錯誤的配置。本文可以作為調查和評估常見原因（有時是非常明顯）的指南。

儘管我們討論的大部分都是效能問題，但是這些問題也有可能會導致節點或例項的驅逐。Oracle叢集和RAC例項依賴於心跳來維持節點關係。如果網路心跳持續無法連通，那麼例項/節點驅逐就會發生 。因此，以下的這些症狀也和節點/例項驅逐相關。

場景:

主要:

• "gc cr block lost" / "gc current block lost" 出現在AWR的top 5等待事件中或者產生了非常多的等待。

其次:

• SQL traces 檔案中多次出現 gc cr requests / gc current request
• 出現 gc cr multiblock requests 等待，每次等待時間都很長而且elapsed times 都一樣。
• 應用的效能和吞吐量都很差
• 透過ifconfig或者其它第三方的工具能夠看到網路上傳送和接受包的錯誤
• 使用netstat命令會看到一些error/retransmits/reassembly failures
• 節點故障和節點通訊錯誤
• 大量的CPU消耗在網路程式上

原因:

• 可能的原因已經在下面的診斷指南中列出（按照出現機率排序）

Global Cache Block Loss診斷指南

1. 網線/網路卡/交換機問題
   
   

   描述: 壞掉的網線連線，錯誤的電纜，製作粗糙的電纜，過於冗長和錯誤的埠分配，有問題的交換機都會導致低下的傳輸率，塊損壞，資料包丟失和效能問題。

   解決: 敦促網路供應商對網路進行檢查，更換壞掉的網路元件。叢集私網應該使用CAT 5 級或者是更好的通訊線纜.所有的裝置都需要確保安全插牢，並且按照線纜和埠進行標識，線纜的長度需要符合供應商指定的要求。

2. UDP receive(rx) buffer sizes設定過小/UDP buffer socket溢位

   描述: Oracle RAC Global cache塊的處理是突發性的，因此，作業系統需要緩衝區來接受接收（RX）資料包並等待CPU的處理,如果緩衝區設定的不合理或者過小會導致塊丟失和global cache 塊丟失。透過'netstat -s' 或者 'netstat -su'命令可以幫助我們在unix平臺上獲取到UDPInoverflows，package receive errors, dropped framces 或packets dropped due to buffer full errors資訊。
   
   解決: 資料包丟失往往是由於在接收伺服器上設定的UDP緩衝區不足，從而導致了塊在緩衝區中溢位而產生塊丟失。當OS的緩衝區設定小於128k的時候，Oracle 在開啟一個socket 時會設定 UDP receive buffer 尺寸為 128k。如果OS的緩衝區設定大於128k，Oracle會採用OS 的設定。如果資料庫的塊尺寸大於8k，那麼緩衝區會自動的進行調整，但是不會超過OS的限制。當DB引數DB_FILE_MULTIBLOCK_READ_COUNT的值大於4時，如果發現 UDP buffer overflows, packet loss 和 lost blocks，並且資料庫出現了大量的"global cache cr requests"等待超時，這是由於緩衝區設定過小導致的，我們可以透過調大OS的UDP緩衝區的或者調低資料庫引數DB_FILE_MULTIBLOCK_READ_COUNT來解決問題 ，這個引數可以在系統或session級別調整。
   
   

   對於大部分的unix平臺，我們可以透過以下的一些命令來判斷是否出現UDP緩衝區溢位或者block loss，執行：

   'netstat -s' 或 'netstat -su'，並根據具體平臺檢視  "udpInOverflowsudpInOverflows", "packet receive errors", "fragments dropped" 或 "outgoing packet drop" 資訊
   
   
   注意：UDP丟包通常會引起更多的延遲，網路頻寬減少，更高的CPU使用率(kernel 和user)，以及消耗更多的記憶體來處理這些包的重傳。
   

   在系統執行時，如果工作節點（執行負載的節點）對應的遠端節點上命令netstat –s的輸出中 "outgoing packets dropped"值顯著的增加，同時增加wmem_default 和 wmem_max到4M（Linux平臺）可以解決問題。

   UDP傳送和接收緩衝區引數是和作業系統有關的，它們可以滾動（rolling）修改（例如：每次1個節點）。

3. 私網效能差並且CPU使用率高，`netstat -s` 出現packet reassembly failures。

   描述: 根據MTU（Maximum Transmission Unit）的尺寸，大的UDP資料包可能被分片，並在多個幀中傳送。這些零散的資料包需要在接收節點上重新組合。高CPU使用率（持續的或者是頻繁的峰值），過小的reassembly buffer或者UDP buffer也會導致塊重組失敗。在接收節點’netstat -s’輸出的 "IP Statistics"部分提示有大量的Internet Protocol (IP)上的"reassembles failed" 和 "fragments dropped after timeout"資訊。分片的報文需要在指定時間（time-to-live）內完成重組（reassemble）。沒有能夠完成重組的分片報文會被丟棄並要求重傳。已經收到，但是由於空間不足沒有進行重組的資料分片會被直接丟棄。

   
   
   `netstat -s` IP stat counters:
        3104582 fragments dropped after timeout
        34550600 reassemblies required
        8961342 packets reassembled ok
        3104582 packet reassembles failed.
   
   解決: 增加reassemble buffer尺寸，給重組分配更多的空間。增加reassemble的時間，增加UDP receive buffer以避免由於網路延遲導致的reassemble失敗，並找到對網路資料包處理產生負面影響的高CPU 利用率原因.
   注意: 增加以下設定的同時也會增加記憶體的使用
   
   
   LINUX:
   我們可以透過以下設定來修改reassemble buffer大小
   /proc/sys/net/ipv4/ipfrag_low_thresh (default = 196608)
   /proc/sys/net/ipv4/ipfrag_high_thresh (default = 262144)
   
   我們可以透過以下設定來修改reassemble的時間:
   /proc/sys/net/ipv4/ipfrag_time (default = 30)
   
   請參考OS文件瞭解不同平臺的對應命令語法。

   以上不適用於RHEL 6.6， RHEL 6.6版本請參考RHEL 6.6: after manually lowered ipfrag_high_thresh IPC Send timeout/node eviction etc with high packet reassembles failure (Doc ID 2008933.1)

4. 網路傳輸壞塊（corruption）導致的UDP checksum errors 和/或 send (tx) / receive (rx) transmission errors

   描述:  UDP包傳輸的過程中，接受程式會讀取資料包頭的校驗值。任何校驗值損壞都會使這個包被丟棄，並導致重發，這會增加CPU的使用率並且延緩資料包處理。

   解決: 使用 tcpdump，snoop等網路工具來捕獲資料包的dump,定位這些checksum錯誤並確認checksum corruption。敦促OS或者網路管理員查詢產生corruption的原因。 已知的問題是由於網路卡上開啟了Checksum offloading 導致了checksum 錯誤，如果出現這樣的問題請檢查checksum offloading的功能是否被禁用，測試後考慮關閉網路卡上的該項功能。在Linux系統上執行ethtool -K <IF> rx off tx off可以關閉該功能.

5. 在通訊通道中設定了不匹配的MTU的值

   描述: 不匹配的MTU大小設定會導致傳輸過程中出現  "packet too big" 錯誤並丟失資料包，導致global cache block丟失和大量的重傳（retransmission）申請。.
   解決: MTU 是"Maximum Transmission Unit" 或者是私網通訊過程中幀的尺寸.

   對於乙太網（Ethernet），大多數UNIX平臺的預設值是1500位元組。私網鏈路中所有裝置都應該定義相同的MTU。請確認並監控私網鏈路中的所有的裝置。為ping ,tracepath,traceroute命令指定大的，非預設尺寸，ICMP probe 包來檢查MTU設定是否存在不一致。使用ifconfig或者廠商推薦的工具為伺服器網路卡（NIC）的MTU設定合適的值。關於JUMBO Frames的設定，請見第12點的介紹。

   注意：私網中不一致的MTU值會導致節點無法加入叢集的問題。

6. 使用非專用的私網連結

   描述: 共享的公網和私網配置會導致應用效能低下，網路擁堵，在一些極端的情況下會導致global cache block loss.
   解決:資料庫/叢集私網應該使用獨佔的VLAN，並定義在non-routed子網中。私網的交換機需要獨立於其他的交換機，例如，私網交換機不應該是從接入層的交換機擴充套件出來,私網的交換機不應該和公網或者NAS的交換機共享。如果使用了VLANs，那麼私網應該被劃分在單獨的VLAN中，並且位於獨佔的 ，non-routed 子網，獨立於公網或者NAS網路。

7. 伺服器/交換機缺少“鄰接”（adjacency）配置

   描述: 通常，如果網路上的裝置能夠透過單跳連結，我們稱為“鄰接”(adjacency).多跳的配置會增加網路上的延遲，也會增加更多的節點故障風險.
   解決: 所有的 GbE(千兆乙太網)伺服器的私網連結都應該鄰接在交換機或者交換機組（如果配置了交換機冗餘）上。在私網鏈路中，不應該出現中間網路裝置，例如：路由器。在Unix平臺上，我們可以透過tracetroute命令來確定“鄰接”問題。

8. 配置了 IPFILTER
   

   描述:配置主機防火牆或網路地址轉換（NAT）軟體-- IPFILTER (IPF)也是導致私網通訊問題的原因之一。IPF還會導致嚴重的應用程式效能下降，丟包以及global cache block loss問題.
   解決: 禁用 IPFILTER

9. 過時的網路卡驅動程式(Network driver)或者是網路卡韌體（firmware）

   描述: 過時的網路卡驅動程式或韌體，是已知的私網資料包傳輸問題原因。不相容的網路卡驅動程式會導致節點間通訊過程中資料包處理延遲，延遲增加和丟包。
   解決： 所有節點上的網路卡應該採用相同的製造商和型號，相同的效能引數，和對稱的插槽(slot) ID。叢集中所有節點的私網網路卡韌體和驅動程式都應該是一致的（最新的）。

10. 特別的私網連結和網路協議

    描述: 非標準的，專享的網路協議，如LLT ，HMP等已經被證明是不穩定的而且很難debug。使用非標準的，專享的網路協議會導致應用的效能下降，丟包和節點重啟等故障。
    解決: Oracle使用1GbE UDP 作為傳輸和通訊協議，這已經被證明是穩定的，可靠的和高效能的。請避免使用特別的和非標準的通訊協議。 在一些平臺上，基於Inifiniband 的IP和RDS協議是可用的並且是Oracle支援的，而且10GbE已經被認證(詳細資訊請參見OTN) - Oracle還在進行這方面的認證工作。

11. 錯誤配置的網路卡繫結/鏈路聚合

    描述:伺服器上錯誤的網路卡繫結或鏈路聚合配置，鄰接的私網交換機上錯誤的聚合配置會導致效能下降，出現由"port flapping"導致的block loss，交換機上構成私網埠的聚合鏈路發生頻繁的"UP"/"DOWN"狀態切換。
    解決： 如果在叢集伺服器上為私網配置了鏈路聚合，那麼交換機上的埠也應該支援這種配置，並按照聚合配置來配合私網的通訊。交換機上構成私網埠的聚合鏈路配置錯誤會導致 'port flapping'，交換機埠會被隨機刪除，導致丟包.對於繫結和聚合，請參考驅動器（driver）文件進行配置，並且在有工作負載的環境下進行測試。 有很多公開的工具和軟體可以協助進行頻寬和效能延遲的測試（請參考iperf）。我們應該透過評估OS,網路和網路驅動器的統計資料來確定繫結的效能.

12. 錯誤的巨幀（Jumbo Frame）配置

    描述: 錯誤的Jumbo Frames配置會產生之前提到的不一致的MTU問題

    解決：Jumbo Frames 並不是IEEE 標準配置，所以配置的時候應該很小心。單個Jumb Frame的大小是9000 bytes左右。Frame 的大小取決於網路裝置供應商，在不同的通訊裝置上的大小可能是不一致的。如果預設的MTU 尺寸不是9000bytes，請保證通訊路徑中的所有裝置（例如：交換機/網路裝置/網路卡）都能夠支援一個統一的MTU值，在操作的過程中必須把Frame Size（MTU Size）配置成這個值。不合適的MTU設定，例如：交換機上配置MTU=1500,但是伺服器上的私網網路卡配置成MTU=9000，這樣會造成丟包，包的碎片和重組的錯誤，這些都會導致嚴重的效能問題和節點異常當機。大部分的平臺上我們都可以透過netstat –s命令的‘IP stats’輸出發現包的碎片和重組的錯誤。大部分的平臺上我們可以透過ifconfig –a命令找到frame size的設定。關於交換機上的配置查詢，需要檢視交換機提供商的文件來確定。

13. 網路卡雙工（ Duplex）模式不匹配

    描述：網路卡的雙工模式不匹配是指，在同一個互動的鏈路上，一端使用的是全雙工模式，另外一端使用的是半雙工模式。這通常是是手動配置錯誤導致的 或者是一端配置被修改成半雙工模式時，另外一端配置成了auto-negotiate引起的。雙工模式不匹配會導致嚴重的私網通訊效能問題

    解決: 叢集中所有節點的私網網路卡和交換機上的私網線路對應的雙工模式都應該配置為auto-negotiate。千兆乙太網標準要求auto-negotiate 設定為”on”。雙工模式不匹配可能會導致嚴重的網路效能下降，資料衝突和丟包的情況出現。 每次進行網路硬體和軟體升級後都應該檢查auto-negotiate設定， Auto-negotiate 在所有的裝置上都應該是1000全雙工模式。

14. 私網通訊鏈路流量控制（Flow-control）不匹配

    描述： 流量控制是指，當一臺伺服器傳輸的速度比接收節點（或者是網路裝置）的接受速度快 。接收裝置會傳送“暫停”幀來請求傳送端暫時停止傳送資料包.
    解決：交換機和伺服器網路卡之間Flow-control設定不匹配的時候會導致丟包和嚴重的網路效能問題。大部分的情況下，預設的設定"ON"是最好的結果。例如：

    tx flow control should be turned on
    rx flow control should be turned on
    tx/rx flow control should be turned on for the switch(es)
    
    

    儘管如此，對於一些特殊的案例(例如 Note 400959.1)，例如一些OS或交換機韌體的bug，設定成OFF(所有的網路路徑)會有更好的結果。

    注意：Flow control的設定在韌體/網路驅動程式升級後會發生變化，網路卡/交換機的設定應該在升級後重新檢查。如果沒有裝置提供商的其它建議值，請使用預設的值。

15. OS，網路卡，交換機層面的資料包丟棄

    描述：任何被OS，網路卡或者交換機提示的包丟棄資訊都應該被徹底的調查和解決。包丟失會導致私網效能降低，CPU使用過高以及節點異常當機等情況

    解決：具體的工具會幫助我們確定包或幀丟失問題發生在那個層面（process/OS/network/switch）。netstat ,ifconfig,ethtool,kstat(依賴於OS的平臺)命令輸出和交換機埠狀態是首先要進行檢查和評估的。您需要一些網路嗅探器（sniffer）跟蹤點對點資料通訊來排查問題（常見的工具：snoop/wireshare/ethereal）.

    注意：從底層來理解丟包的原因是我們找到根本原因不可缺少的步驟。在網路環境中，過小的網路卡ring buffers或者receive queues是已知的導致網路上異常丟包的原因，比如：在所有層面都沒有提示發生了丟包。請檢視下面的網路卡驅動問題和Kernel queue長度.這種情況，需要聯絡系統管理員和網路工程師來確定根本的原因.

16. 網路卡驅動/韌體配置問題

    描述：不合適的配置或者網路卡中一些可調屬性的不恰當的預設也會導致丟包並增加重傳的請求.

    解決：大部分網路裝置供應商提供的預設出廠配置是可以滿足應用要求的。儘管如此，一些網路供應商提供的網路卡裝置需要修改interrupt coalescence設定和ring buffers描述符數量。interrupt coalescence是CPU傳送和接受資料包的中斷率。ring buffer在 CPU中斷之間持有需要處理的rx 包。不合適的配置會導致在這個層面丟失資料包，診斷這個層面的問題需要系統管理員以及OS/裝置提供商的參與。

17. 網路卡傳送(tx)和接受（rx）佇列的長度

    描述：設定過小的網路卡tx/rx佇列長度會導致在佇列滿的時候出現丟包的情況，這會導致gc block loss，增加重傳並且降低私網的效率。

    解決：在核心網路子系統（kernel network subsystem）和網路介面裝置驅動程式之間移動資料時，傳送（TX）和接收（Rx）佇列用來實現對資料包的傳輸和處理進行管理.這些佇列的大小是可以配置的。針對產生的網路流量或者配置了MTU的情況，如果這些佇列的配置不合適或者過小，佇列填滿後會導致資料包的丟失或溢位。取決於裝置的驅動程式和蒐集到的統計資訊數量，這類丟包是不容易被發現的，診斷這個層面的問題需要系統管理員和OS/裝置的提供商的介入。（通常在linux上我們設定引數：iftxtqueue 和netdev_max_backlog）

18. 有限的負載能力和過於飽和的頻寬

    描述： 過載的網路使用也會導致私網的效能問題和丟包。

    解決： 私網配置的最佳實踐是您需要知道您的網路使用情況和頻寬。這需要透過定期的監控來獲取使用的趨勢，瞬時值和恆定的值。私網上突然增加的使用請求可能是應用程式調整或異常導致的，如效能很差的SQL語句或者異常產生的資料流量。找到產生頻寬飽和的原因並解決它。

19. 過度的CPU申請和排程延遲

    描述： 持續的高負載和網路堆疊的排程延遲也會對私網的資料包傳輸產生負面的影響並且會導致私網的效能下降，丟包，gc block loss和節點的重啟問題。

    解決： 持續的高CPU使用率導致的排程延遲也會導致網路上資料包的延遲處理。過度，持續的延遲會導致嚴重的效能下降，並可能導致群集節點故障。關鍵是要找到持續的高CPU使用率的原因。使用uptime命令能夠列出大部分作業系統的平均負載情況，和網路堆疊處理相關的CPU問題，可以透過NIC interrupt coalescence或者繫結網路到單個CPU得到緩解，請和網路裝置的供應商一起來進行此類的最佳化。排程延遲會導致資料包重組錯誤。請參見本文的第2點。

20. 和交換機相關的資料包處理問題

    描述：交換機的埠緩衝區溢位，交換機擁堵和配置問題，比如MTU大小，網路聚合和VLANS 都能導致低效率的資料包處理和叢集節點故障。

    解決：Oracle私網需要一個包含交換機的乙太網網路。交換機是私網中點對點通訊至關重要的組成部分。作為一個網路裝置，這個交換機會受到多種因素的影響並導致私網通訊效能和高可用性出現異常。監控交換機的異常，資料包處理事件，臨時的或持續的吞吐量資訊是非常重要的。交換機的狀態統計資訊，應該定期進行檢查並評估是否正常，並找出異常情況。

21. QoS對私網資料包處理產生的負面影響

    描述：在交換機上定義的QoS會共享私網通訊的頻寬並影響私網處理能力，導致私網效能的下降。

    解決： 如果私網布置在共享交換機的VLAN上，QoS應該透過優先順序配置來避免對私網通訊產生負面的影響。任何QoS的定義在佈置前都應該進行評估，確保不會影響私網通訊.

22. 重聚（reconvergence）過程中生成樹（Spanning tree）限電
    

    描述：乙太網使用生成樹協議(STP)來避免網路環路，確保交換機和冗餘的交換機能直接路由到伺服器。任何包含在STP拓撲中的裝置故障都會導致重新計算路由到主機的重聚。如果STP協議在區域網中被起用，但是配置的有問題或未經最佳化，網路重聚事件可能需要長達1分鐘或者更長的時間（取決於網路的規模和參與裝置）。這種延遲會導致私網問題和叢集範圍的中斷。

    解決：很多交換機供應商提供最佳化的擴充套件，使STP能夠實現更快的網路重聚。例如： Rapid Spanning Tree (RSTP), Per-VLAN Spanning Tree (PVST)和Multi-Spanning Tree (MSTP) 可以避免叢集大範圍的異常出現。

23. STREAMS佇列的sq_max_size 配置太小

    描述： AWR 提示  "gc cr block lost" 和/或"gc current block lost"等待時間很高。 netstat 並沒有提示有任何資料包處理的錯誤. `kstat -p -s '*nocanput*` 返回非0值. nocanput 說明streaming message佇列已滿，並且包被丟棄。 客戶在Solaris平臺RAC環境下使用STREAMS。
    解決： 增加UDP max buffer space，並且把STREAMS佇列設定成unlimited能夠解決問題，並且消除"nocanput" lost messges。以下是Solaris平臺下對應的命令：
    
    `ndd -set /dev/udp udp_max_buf <NUMERIC VALUE>`
    set sq_max_size to 0 (unlimited) in /etc/system. Default = 2
    
    udp_max_buf 控制UDP socket傳送和接受緩衝區的大小，預設值是262,144 bytes，這個值對於使用STREAMS的應用來說是不夠用的。sq_max_size 控制message的佇列的長度。
    
    
24. VIPA和DGD設定不正確（僅限Aix平臺）
    
    

    如果您在AIX平臺上使用了VIPA（Virtual IP Address），那麼Dead Gateway Detection (DGD)必須配置成允許UDP failover模式。

    預設的DGD引數可以作為配置起始值，但是在一些客戶的環境中，這些引數可能需要調整，但是無論何種情況，都必須設定成大於1的值。預設的設定如下：
    dgd_packets_lost = 3
    dgd_ping_time = 5
    dgd_retry_time = 5
    
    更多配置資訊，請參考文章Using VIPA and Dead Gateway Detection on AIX for High Availability Networks, including Oracle RAC：

25. Solaris+Vertis LLT的環境上，交換機的錯誤配置

                  當VCS命令lltstat的輸出顯示"Snd retransmit data"增加時，gc block lost 也會增加。把私網交換機的速度從fixed修改成auto-negotiate，更均勻地分佈電纜到每個模組的連結，這樣有助於解決"gc blocks lost"的問題。

                26.  對於12.1.0.2, FALSE 'GC BLOCKS LOST' REPORTED ON 12.1 AFTER UPGRADING FROM 11.2.0.3

這個問題正在測試階段,請聯絡Oracle技術支援.

更改

正如上面解釋的，塊丟失問題通常是由不可靠的私有網路造成的。這可能是由於一個不良補丁或錯誤的網路配置或硬體問題導致的。

原因

大多數情況下 ， gc block lost 問題是由於：(a) 缺少OS補丁 (b) 壞掉的網路卡 (c) 有問題的線纜 (d) 有問題的交換機 (e) 網路設定 造成的。

客戶應該向OS 供應商諮詢並提供 OSWatcher 輸出。

解決方案

客戶需要收集OS watcher資料 (參見 Note 301137.1).

這些資料需要提供給OS供應商來找到問題的根本原因。

KEYWORDS: GC_BLOCKS_LOST, block loss, interconnect, eviction
RAC, node failure, poor performance, evictions, gc_blocks_lost, RAC Performance

解決

參考