一次gc buffer busy問題的診斷
最近在做系統上線的效能測試，在測試過程中發現了一個與gc buffer busy相關的效能問題，經過一份周折，最終解決問題。
總體來說，這次測試的現象是有三個節點的壓力正常，事務處理效率也正常，但另外一個節點事務處理能力很差，且系統負載根本上不去。
以下是解決過程。
[@more@]首先使用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的等待時間也下降到與其他幾臺一樣的水平，問題得到解決。
總體來說，這次測試的現象是有三個節點的壓力正常，事務處理效率也正常，但另外一個節點事務處理能力很差，且系統負載根本上不去。
以下是解決過程。
[@more@]首先使用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的等待時間也下降到與其他幾臺一樣的水平，問題得到解決。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/231499/viewspace-1044221/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- GC BUFFER BUSY問題的診斷GC
- gc buffer busy acquire問題處理GCUI
- 一次GC BUFFER BUSY處理GC
- gc buffer busyGC
- gc buffer busy的優化GC優化
- 記一次gc buffer busy等待事件的處理GC事件
- 記一次使用gdb診斷gc問題全過程GC
- .記一次使用gdb診斷gc問題全過程GC
- gc buffer busy的最佳化GC
- wait event:gc buffer busyAIGC
- GC機制和OutOfMemory問題的診斷GC
- rac 遭遇GC BUFFER BUSY 處理思路GC
- Buffer Cache以及buffer busy waits/gc相關事件AIGC事件
- RAC遇到GC Buffer Busy的解決方法2GC
- RAC遇到GC Buffer Busy的解決方法1GC
- 一次網路問題的診斷（二）
- GC Buffer Busy Waits in RAC: Finding Hot BlocksGCAIBloC
- SQL問題診斷SQL
- 分析解決11gR2 雙節點RAC環境下的gc cr block busy/gc buffer busy acquire等待GCBloCUI
- GreysJava線上問題診斷工具Java
- 問題診斷和PLSQL方面SQL
- 一次對pool的誤用導致的.net頻繁gc的診斷分析GC
- 一次ORA-4030問題診斷及解決（三）
- 使用crsctl工具診斷cluster問題
- Oracle Buffer Busy WaitsOracleAI
- buffer busy wait 解析AI
- buffer busy wait 的深度剖析AI
- RAC 環境中 gc block lost 和私網通訊效能問題的診斷 (文件 ID 1674865.1)GCBloC
- 使用MTR命令診斷網路問題
- Oracle Stream實戰(10)—問題診斷Oracle
- Oracle效能問題診斷一例Oracle
- J2EE效能問題的診斷示例
- 熊貓大俠一次效能診斷優化十一問優化
- 【等待事件】buffer busy waits事件AI
- Buffer Busy Wait小結AI
- zt_buffer busy waitAI
- 【MOS】RAC 環境中 gc block lost 和私網通訊效能問題的診斷 (文件 ID 1674865.1)GCBloC
- 如何診斷RAC系統中的'gc cr multi block request'?GCBloC