我遇到一次该等待事件导致的系统严重的效率问题，现象有点类似，后通过将私有网卡间的连接（网线到配线架再到交换机）换成一个以太网线直连暂时解决。

####################################################

如下是某个类似案例：

最近在做系统上线的性能测试，在测试过程中发现了一个与gc buffer busy相关的性能问题，经过一份周折，最终解决问题。

总体来说，这次测试的现象是有三个节点的压力正常，事务处理效率也正常，但另外一个节点事务处理能力很差，且系统负载根本上不去。

以下是解决过程。

首先使用spawrrac.sql出一个RAC AWR报表，以下是关注的主要部分：

OS Stat
~~~~~~~
Num Load Load
Inst # CPUs Begin End % Busy % Usr % Sys % WIO % Idl Busy Time (s) Idle Time (s) Total time (s)
------ ---- ------ ------ ------ ------ ------ ------ ------ --------------- --------------- ---------------
1 64 34.1 28.0 34.7 31.2 2.3 19.6 65.3 159,990.51 301,169.36 461,159.87
2 64 2.3 3.4 2.7 1.9 .3 .0 97.3 12,428.21 448,726.00 461,154.21
3 64 30.1 19.6 27.7 24.7 1.8 19.2 72.3 127,564.55 333,594.01 461,158.56
4 64 46.3 30.3 36.0 32.0 2.8 19.8 64.0 165,966.72 295,197.09 461,163.81
--------------- --------------- ---------------
sum 465,949.99 1,378,686.46 1,844,636.45

这部分可以看到OS的负载情况，可以看到节点2负载非常低。

SysStat (Absolute Values)
~~~~~~~~~~~~~~~~~~~~~~~~~~

+--- Sessions --+ +------ Open Cursors -----+ +- Session Cached Cursors -+
I# Begin End Begin End Begin End
---- -------- -------- -------------- ------------ -------------- ------------
1 201 277 2,120 3,133 11,820 19,773
2 333 369 3,491 4,178 4,063 5,093
3 227 149 2,477 1,470 6,146 13,223
4 319 245 3,694 2,734 7,348 18,586
-------- -------- -------------- ------------ -------------- ------------
sum 1,080 1,040 11,782 11,515 29,377 56,675

从部分可以看到，节点2的active session最多。实际上给各个节点加的压力是差不多的，而节点2的活动会话这么多，说明它的处理速度慢，导致会话堆积比较多。
从另外的角度来说，活动会话多的节点反而空闲，说明整个事务处理流程在某一个地方被堵住了，出现瓶颈了，所以压力到不了OS这一层。
Avg
Wait %Time Total Wait Wait % of
I# Class Event Waits -outs Time(s) (ms) DB time
---- -------- ---------------------------------------- ---------- ------ ------------- ------- -------
1 Cluster gc buffer busy ########## .0 459,472.12 3.5 21.08
2 Cluster gc buffer busy 4,129,532 .0 1,848,007.80 447.5 88.76
3 Cluster gc buffer busy ########## .0 324,819.93 3.6 16.91
4 Cluster gc buffer busy ########## .0 532,179.32 3.8 17.58

看到这部分，基本就可以确定瓶颈在什么地方了：gc buffer busy 。造成这个等待的原因有很多，在这个例子中，因为测试数据和用例是一样的，但是平均等待时间差别上百倍，这个基本可以确定不是因为数据库导致的。
不是数据库原因的话，那这个等待与inter connect的效率关系最大，所以就开始怀疑是网络原因导致的。

在这个系统中，用于cache fusion的网络用的是两个万兆网卡绑定成一主一备的形式提供服务的。
首先看看网卡的绑定情况：

[oracle@dwdb01 ~]$ cat /proc/net/bonding/bond1
Ethernet Channel Bonding Driver: v3.4.0 (October 7, 2008)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth5
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth5
MII Status: up
Link Failure Count: 0
Permanent HW addr: d8:d3:85:a0:5c:4c

Slave Interface: eth7
MII Status: up
Link Failure Count: 0
Permanent HW addr: d8:d3:85:a0:4c:fc

dwdb01/03/04的绑定配置都一样，都是eth5是活动网卡，eth7是standby网卡。

[root@dwdb02 ~]# cat /proc/net/bonding/bond1
Ethernet Channel Bonding Driver: v3.4.0 (October 7, 2008)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth7
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth5
MII Status: up
Link Failure Count: 0
Permanent HW addr: d8:d3:85:a0:4c:6c

Slave Interface: eth7
MII Status: up
Link Failure Count: 0
Permanent HW addr: d8:d3:85:9f:9b:14

dwdb02和上面三台刚好相反，eth7是活动网卡，eth5是standby。而正好出问题的是dwdb02，到了这里，这个嫌疑就很大了。
接着咨询负责网络的同事，交换机也有两台同时提供服务的，这几个节点上的eth5接的是其中一台交换机，eth7接的是另外一台交换机，而交换机内的通信效率和交换机间的通信效率差别是很大的。
如果是这个原因的话，那把节点2的活动网卡改为eth5，让所有活动网卡在同一台交换机应该就可以解决问题了。

于是开始切换：
[root@dwdb02 ~]# ifdown eth7
[root@dwdb02 ~]# cat /proc/net/bonding/bond1
Ethernet Channel Bonding Driver: v3.4.0 (October 7, 2008)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth5
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth5
MII Status: up
Link Failure Count: 0
Permanent HW addr: d8:d3:85:a0:4c:6c
[root@dwdb02 ~]# ifup eth7
[root@dwdb02 ~]# cat /proc/net/bonding/bond1
Ethernet Channel Bonding Driver: v3.4.0 (October 7, 2008)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth5
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth5
MII Status: up
Link Failure Count: 0
Permanent HW addr: d8:d3:85:a0:4c:6c

Slave Interface: eth7
MII Status: up
Link Failure Count: 0
Permanent HW addr: d8:d3:85:9f:9b:14

通过停止、启动eth7，让网卡failover来实现切换。
切换后压力立马上去，gc buffer busy的等待时间也下降到与其他几台一样的水平，问题得到解决。

原文转自：http://space6212.itpub.net/post/12157/511707

ITPub博客

GC BUFFER BUSY问题的诊断

最新文章