?RAC 數(shù)據(jù)庫上比較常見的一種問題就是“IPC Send timeout”。數(shù)據(jù)庫Alert log中出現(xiàn)了“IPC Send timeout”之后，經(jīng)常會伴隨著ora-29740 或者 "Waiting for clusterware split-brain resolution"等，數(shù)據(jù)庫實(shí)例會因此異常終止或者被驅(qū)逐出集群。

比如:

實(shí)例1的ALERT LOG：

Thu Jul 02 05:24:50 2012
IPC Send timeout detected.Sender: ospid 6143755<==發(fā)送者
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 <==出現(xiàn)腦裂
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分鐘，實(shí)例2被驅(qū)逐出集群

實(shí)例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? <==實(shí)例2出現(xiàn)ORA-29740錯(cuò)誤，并被驅(qū)逐出集群
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實(shí)例間主要的通訊進(jìn)程有LMON, LMD, LMS等進(jìn)程。正常來說，當(dāng)一個(gè)消息被發(fā)送給其它實(shí)例之后，發(fā)送者期望接收者會回復(fù)一個(gè)確認(rèn)消息，但是如果這個(gè)確認(rèn)消息沒有在指定的時(shí)間內(nèi)收到（默認(rèn)300秒），發(fā)送者就會認(rèn)為消息沒有達(dá)到接收者，于是會出現(xiàn)“IPC Send timeout”問題。

??? 這種問題通常有以下幾種可能性：
1. 網(wǎng)絡(luò)問題造成丟包或者通訊異常。
2. 由于主機(jī)資源(CPU、內(nèi)存、I/O等）問題造成這些進(jìn)程無法被調(diào)度或者這些進(jìn)程無響應(yīng)。
3. Oracle Bug.

?? 在這方面的Oracle Bug不是太多，大多數(shù)時(shí)候都是網(wǎng)絡(luò)或者資源問題造成這種情況。

?? 為了分析這種問題，網(wǎng)絡(luò)和資源監(jiān)控工具是非常必要的。推薦安裝OSWBB，對于如何安裝和使用OSWBB，請參考文章利器OSW (OSWatcher Black Box) 之簡介篇。

?? 下面是一個(gè)由于主機(jī)資源緊張?jiān)斐傻摹癐PC Send timeout”例子：

?? 實(shí)例1的Alert log中顯示接收者是2號機(jī)的進(jìn)程1596935，

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

?? 查看當(dāng)時(shí)2號機(jī)的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%被使用

? 上面這個(gè)例子說明當(dāng)主機(jī)CPU負(fù)載非常高的時(shí)候，接收進(jìn)程無法響應(yīng)發(fā)送者，從而引發(fā)了“IPC Send timeout”。

? 下面是一個(gè)由于網(wǎng)絡(luò)問題造成的“IPC Send timeout”例子：

?? 實(shí)例1的Alert log中顯示接收者是2號機(jī)的進(jìn)程49715160，

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

?? 查看當(dāng)時(shí)2號機(jī)的OSWatcher的vmstat輸出，沒有發(fā)現(xiàn)CPU和內(nèi)存緊張的問題，查看OSWatcher的netstat輸出，在發(fā)生問題前幾分鐘，私網(wǎng)的網(wǎng)卡上有大量的網(wǎng)絡(luò)包傳輸。

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 個(gè)包/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 個(gè)包/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 個(gè)包/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 個(gè)包/30秒

查看這個(gè)系統(tǒng)正常的時(shí)候，大概每30秒傳輸幾千個(gè)包：

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個(gè)包/30秒

?? 這種突然的大量的網(wǎng)絡(luò)傳輸可能會引發(fā)網(wǎng)絡(luò)傳輸異常。對于這種情況，需要聯(lián)系網(wǎng)管對網(wǎng)絡(luò)進(jìn)行檢查。在某些案例中，重啟私網(wǎng)交換機(jī)或者調(diào)換了交換機(jī)后問題不再發(fā)生。（請注意，網(wǎng)絡(luò)的正常的傳輸量會根據(jù)硬件和業(yè)務(wù)的不同而不同。）

下面是一個(gè)由于I/O問題造成的“IPC Send timeout”例子：

?? 實(shí)例的Alert log中顯示接收者是1號機(jī)的LMON進(jìn)程：

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

查看這個(gè)進(jìn)程生成的trace文件db1_lmon_44105801.trc，發(fā)現(xiàn)當(dāng)時(shí)LMON的函數(shù)都是和IO有關(guān)的：

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

?? 總結(jié)一下，對于“IPC Send timeout”：
1) 通過Oracle自帶的CHM (Cluster Health Monitor)的輸出來檢查當(dāng)時(shí)的資源、網(wǎng)絡(luò)使用情況。CHM只在某些平臺和版本上存在，關(guān)于CHM，請參考文章11gR2 新特性：Oracle Cluster Health Monitor(CHM)簡介。
2) 如果沒有CHM，請安裝OSWBB來監(jiān)控網(wǎng)絡(luò)和主機(jī)資源。
3) 檢查網(wǎng)絡(luò)上是否有UDP或者IP包丟失的情況、網(wǎng)絡(luò)上是否有錯(cuò)誤。
4) 檢查所有節(jié)點(diǎn)的網(wǎng)絡(luò)設(shè)置是否正確。比如，所有節(jié)點(diǎn)MTU的設(shè)置必須是一致的，如果Jumbo Frame被使用的話，需要保證交換機(jī)可以支持MTU為9000.
5) 檢查服務(wù)器是否有CPU使用率高或者內(nèi)存不足的情況。
6) 檢查實(shí)例被驅(qū)逐之前是否有數(shù)據(jù)庫hang或者嚴(yán)重的性能問題。

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

與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的如何诊断RAC数据库上的“IPC Send timeout”问题？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。