如何診斷RAC資料庫上的“IPC Send timeout”問題？

RAC 資料庫上比較常見的一種問題就是“IPC Send timeout”。資料庫Alert log中出現了“IPC Send timeout”之後，經常會伴隨著ora-29740 或者 "Waiting for clusterware split-brain resolution"等，資料庫例項會因此異常終止或者被驅逐出叢集。

比如:

例項1的ALERT LOG：

Thu Jul 02 05:24:50 2012
IPC Send timeout detected.Sender: ospid 6143755<==傳送者
Receiver: inst 2 binc 1323620776 ospid 49715160<==接收者
Thu Jul 02 05:24:51 2012
IPC Send timeout to 1.7 inc 120 for msg type 65516 from opid 13
Thu Jul 02 05:24:51 2012
Communications reconfiguration: instance_number 2
Waiting for clusterware split-brain resolution <==出現腦裂
Thu Jul 02 05:24:51 2012
Trace dumping is performing id=[cdmp_20120702052451]
Thu Jul 02 05:34:51 2012
Evicting instance 2 from cluster <==過了10分鐘，例項2被驅逐出叢集

例項2的ALERT LOG：

Thu Jul 02 05:24:50 2012
IPC Send timeout detected. Receiver ospid 49715160 <==接收者
Thu Jul 02 05:24:50 2012
Errors in file /u01/oracle/product/admin/sales/bdump/sales2_lms6_49715160.trc:
Thu Jul 02 05:24:51 2012
Waiting for clusterware split-brain resolution
Thu Jul 02 05:24:51 2012
Trace dumping is performing id=[cdmp_20120702052451]
Thu Jul 02 05:35:02 2012
Errors in file /u01/oracle/product/admin/sales/bdump/sales2_lmon_6257780.trc:
ORA-29740: evicted by member 0, group incarnation 122  <==例項2出現ORA-29740錯誤，並被驅逐出叢集
Thu Jul 02 05:35:02 2012
LMON: terminating instance due to error 29740
Thu Jul 02 05:35:02 2012
Errors in file /u01/oracle/product/admin/sales/bdump/sales2_lms7_49453031.trc:
ORA-29740: evicted by member , group incarnation

    在RAC例項間主要的通訊程式有LMON, LMD, LMS等程式。正常來說，當一個訊息被髮送給其它例項之後，傳送者期望接收者會回覆一個確認訊息，但是如果這個確認訊息沒有在指定的時間內收到（預設300秒），傳送者就會認為訊息沒有達到接收者，於是會出現“IPC Send timeout”問題。

    這種問題通常有以下幾種可能性：
1. 網路問題造成丟包或者通訊異常。
2. 由於主機資源(CPU、記憶體、I/O等）問題造成這些程式無法被排程或者這些程式無響應。
3. Oracle Bug.

   在這方面的Oracle Bug不是太多，大多數時候都是網路或者資源問題造成這種情況。

   為了分析這種問題，網路和資源監控工具是非常必要的。推薦安裝OSWBB，對於如何安裝和使用OSWBB，請參考文章利器OSW (OSWatcher Black Box) 之簡介篇。

   下面是一個由於主機資源緊張造成的“IPC Send timeout”例子：

   例項1的Alert log中顯示接收者是2號機的程式1596935，

Fri Aug 01 02:04:29 2008 
 IPC Send timeout detected.Sender: ospid 1506825 <==傳送者
 Receiver: inst 2 binc -298848812 ospid 1596935  <==接收者

   檢視當時2號機的OSWatcher的vmstat輸出：

 zzz ***Fri Aug 01 02:01:51 CST 2008 
 System Configuration: lcpu=32 mem=128000MB 
 kthr     memory             page              faults        cpu     
 ----- ----------- ------------------------ ------------ ----------- 
  r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa 
 25  1 7532667 19073986   0   0   0   0    5   0 9328 88121 20430 32 10 47 11 
58  0 7541201 19065392   0   0   0   0    0   0 11307 177425 10440 87 13  0  0 <==idle的CPU為0，說明CPU100%被使用
61  1 7552592 19053910   0   0   0   0    0   0 11122 206738 10970 85 15  0  0 

 zzz ***Fri Aug 01 02:03:52 CST 2008 
   System Configuration: lcpu=32 mem=128000MB 
   kthr     memory             page              faults        cpu     
 ----- ----------- ------------------------ ------------ ----------- 
  r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa 
 25  1 7733673 18878037   0   0   0   0    5   0 9328 88123 20429 32 10 47 11 
81  0 7737034 18874601   0   0   0   0    0   0 9081 209529 14509 87 13  0  0 <==CPU的run queue非常高
80  0 7736142 18875418   0   0   0   0    0   0 9765 156708 14997 91  9  0  0 <==idle的CPU為0，說明CPU100%被使用

  上面這個例子說明當主機CPU負載非常高的時候，接收程式無法響應傳送者，從而引發了“IPC Send timeout”。

  下面是一個由於網路問題造成的“IPC Send timeout”例子：

   例項1的Alert log中顯示接收者是2號機的程式49715160，

Thu Jul 02 05:24:50 2012
IPC Send timeout detected.Sender: ospid 6143755 <==傳送者
Receiver: inst 2 binc 1323620776 ospid 49715160 <==接收者

   檢視當時2號機的OSWatcher的vmstat輸出，沒有發現CPU和記憶體緊張的問題，檢視OSWatcher的netstat輸出，在發生問題前幾分鐘，私網的網路卡上有大量的網路包傳輸。

Node2:
zzz Thu Jul 02 05:12:38 CDT 2012
Name  Mtu   Network     Address            Ipkts Ierrs    Opkts Oerrs  Coll
en1   1500  10.182.3    10.182.3.2       4073847798     0 512851119     0     0 <==4073847798 - 4073692530 = 155268 個包/30秒

zzz Thu Jul 02 05:13:08 CDT 2012
Name  Mtu   Network     Address            Ipkts Ierrs    Opkts Oerrs  Coll
en1   1500  10.182.3    10.182.3.2       4074082951     0 513107924     0     0 <==4074082951 - 4073847798 = 235153 個包/30秒

Node1:
zzz Thu Jul 02 05:12:54 CDT 2012
Name  Mtu   Network     Address            Ipkts Ierrs    Opkts Oerrs  Coll
en1   1500  10.182.3    10.182.3.1       502159550     0 4079190700     0     0 <==502159550 - 501938658 = 220892 個包/30秒

zzz Thu Jul 02 05:13:25 CDT 2012
Name  Mtu   Network     Address            Ipkts Ierrs    Opkts Oerrs  Coll
en1   1500  10.182.3    10.182.3.1       502321317     0 4079342048     0     0 <==502321317 - 502159550 = 161767 個包/30秒

檢視這個系統正常的時候，大概每30秒傳輸幾千個包：

zzz Thu Jul 02 04:14:09 CDT 2012
Name  Mtu   Network     Address            Ipkts Ierrs    Opkts Oerrs  Coll
en1   1500  10.182.3    10.182.3.2       4074126796     0 513149195     0     0 <==4074126796 - 4074122374 = 4422個包/30秒

   這種突然的大量的網路傳輸可能會引發網路傳輸異常。對於這種情況，需要聯絡網管對網路進行檢查。在某些案例中，重啟私網交換機或者調換了交換機後問題不再發生。（請注意，網路的正常的傳輸量會根據硬體和業務的不同而不同。）

下面是一個由於I/O問題造成的“IPC Send timeout”例子：

   例項的Alert log中顯示接收者是1號機的LMON程式：

Sun Feb 22 07:57:30 2014
IPC Send timeout detected. Receiver ospid 44105801 [oracle@db1 (LMON)] <========================接收者

檢視這個程式生成的trace檔案db1_lmon_44105801.trc，發現當時LMON的函式都是和IO有關的：

kjxgmpoll: stalled for 94 seconds (threshold 42 sec)

----- Call Stack Trace -----
skdstdst <- ksedst1 <- ksedst <- dbkedDefDump <- ksedmp
       <- ksdxfdmp <- ksdxcb <- sspuser <- 48bc <- sigthreadmask
        <- sslsstehdlr <- sslsshandler <- 48bc <- skgfsio <- skgfqio
         <- ksfd_skgfqio <- ksfd_io <- ksfdread <- kfk_ufs_sync_io <- kfk_submit_ufs_io
          <- kfk_submit_io <- kfk_io1 <- kfkRequest <- kfk_transitIO <- kfioSubmitIO 
           <- kfioRequestPriv <- kfioRequest <- ksfd_kfioRequest <- 576 <- ksfd_osmio
            <- ksfd_io <- ksfdread <- kccrbp <- kccgrd <- kjxgrf_rr_read
             <- kjxgrDD_rr_read <- kjxgrimember <- kjxggpoll <- kjfmact <- kjfdact
              <- kjfcln <- ksbrdp <- opirip <- opidrv <- sou2o
               <- opimai_real <- ssthrdmain <- main <- start

   總結一下，對於“IPC Send timeout”：
1) 透過Oracle自帶的CHM (Cluster Health Monitor)的輸出來檢查當時的資源、網路使用情況。CHM只在某些平臺和版本上存在，關於CHM，請參考文章11gR2 新特性：Oracle Cluster Health Monitor(CHM)簡介。
2) 如果沒有CHM，請安裝OSWBB來監控網路和主機資源。
3) 檢查網路上是否有UDP或者IP包丟失的情況、網路上是否有錯誤。
4) 檢查所有節點的網路設定是否正確。比如，所有節點MTU的設定必須是一致的，如果Jumbo Frame被使用的話，需要保證交換機可以支援MTU為9000.
5) 檢查伺服器是否有CPU使用率高或者記憶體不足的情況。
6) 檢查例項被驅逐之前是否有資料庫hang或者嚴重的效能問題。

  在下面的MOS文件中有針對“IPC Send timeout”的介紹：
  Top 5 issues for Instance Eviction (Doc ID 1374110.1)