GC BUFFER BUSY問題的診斷

luckyfriends發表於2012-12-19
我遇到一次該等待事件導致的系統嚴重的效率問題,現象有點類似,後透過將私有網路卡間的連線(網線到配線架再到交換機)換成一個乙太網線直連暫時解決。
####################################################
如下是某個類似案例:
最近在做系統上線的效能測試,在測試過程中發現了一個與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部落格 ” ,連結:http://blog.itpub.net/14710393/viewspace-751342/,如需轉載,請註明出處,否則將追究法律責任。

相關文章