如何诊断RAC数据库上的“IPC Send timeout”问题

关注

转载最新推荐文章于 2026-09-25 14:24:02 发布 1.4k 阅读 AI 写同款· GEO 优化 ›

IPC Send timeout detected. Receiver ospid IPC超时的问题 IPC Send timeout 是 Oracle10g Rac中非常让人头痛的一个问题，在资源紧张、网络拥堵等情况下，就有可能发生IPC超时的问题，而RAC随后就会将问题节点驱逐，引发一轮重新配置。可喜的是Metalink上针对10.2.0.3有了一个Patch可以修正，而且在10.2.0.4中彻底修正了该问题。这个BUG号是Bug 519059610.2.0.3的确常有这个问题，而10.2.0.4却很少看到。阅读详情

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或者严重的性能问题。