如何診斷RAC系統中的'gc cr multi block request'?
如何診斷RAC系統中的'gc cr multi block request'?
'gc cr multi block request' 是RAC資料庫上比較常見的一種等待事件,在RAC 上進行全表掃描(Full Table Scan)或者全索引掃描(Index Fast Full Scan)時,容易產生這樣的多塊讀等待。
這種等待產生的主要原因:
1. 資料庫引數db_file_multiblock_read或者db_block_size設定太大,導致多塊讀時GC傳輸量太大;
2. OS上UDP相關的引數設定不夠大導致接收傳送UDP的快取區溢位;
3. 私網效能;
4. LMS設定問題(個數不足或者不是實時執行(real time))導致LMS的處理能力不夠,不能及時傳輸global cache data/message。
這方面的Bug比較少,在11.2之前有一個BUG 8464597,當db_block_size = 32k時,引發大量"gc cr multi block request" 而且效能下降,這個Bug在11.2已經修復。
很多情況下,降低DB_FILE_MULTIBLOCK_READ_COUNT 並且 加大OS UDP相關引數會將極大緩解'gc cr multi block request' 等待。
最近處理了一個問題,從10.2升級到11.2.0.3後產生大量'gc cr multi block request' 等待,發現DB_FILE_MULTIBLOCK_READ_COUNT, UDP 引數等都沒有改變,只是升級後LMS的個數在不同例項間不同而且下降了很多,後來把LMS個數增加並且各個例項值保持一致後,問題得到解決。
Avg
wait % DB
Event Waits Time(s) (ms) time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
gc cr multi block request 632,923 32,441 51 35.5 Cluster
DB CPU 13,518 14.8
gc cr grant 2-way 327,717 10,900 33 11.9 Cluster
gc current grant 2-way 190,856 6,855 36 7.5 Cluster
gc current block 2-way 101,154 3,792 37 4.1 Cluster
如果發現AWR TOP5 等待中存在'gc cr multi block request' 而且它的Avg wait(ms)較高,那麼請參考下面的診斷步驟:
第一步,檢視db_file_multiblock_read_count和db_block_size引數設定。
SQL>show parameter db_block_size
SQL>show parameter db_file_multiblock_read_count
db_block_size一般為8192, db_file_multiblock_read_count一般為16.
第二步,參看OS udp相關引數設定,udp 的引數在不同的OS上是不同的,這些引數會設定UDP的接收快取區和傳送快取區的大小,一般來說接收緩存區要>=傳送快取區。 如果在生產庫修改這些引數,最好諮詢OS廠商瞭解注意事項。
AIX上:
#no –a
udp_recvspace
udp_sendspace
o 設定udp_sendspace >=[(DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT) + 4096],但是不低於 65536.
比如,DB_BLOCK_SIZE=8192, DB_FILE_MULTIBLOCK_READ_COUNT=16,那麼udp_sendspace>= (8192 * 16) + 4096=135168.注意這個值只是最低值,並不是Oracle要求必須設定這麼大。
o 設定udp_recvspace 為 4到10倍 udp_sendpace
o 由於sb_max 必須 >= udp_recvspaceIf ,可能需要增加sb_max的值(預設為1048576)
o 如果udp的引數設定不合理,可能會產生“socket buffer overflows”,如果這個值非0, 需要增加udp_recvspace:
netstat -s | grep "socket buffer overflows"
o 參考資料:
Minimum Software Versions and Patches Required to Support Oracle Products on IBM Power Systems (Doc ID 282036.1)
Linux上:
#More /etc/sysctl.conf
net.core.rmem_default
net.core.rmem_max
net.core.wmem_default
net.core.wmem_max
官方文件上要求的最低值:
Oracle Database Installation Guide
11g Release 2 (11.2) for Linux
E24321-07
rmem_default 262144
rmem_max 4194304
wmem_default 262144
wmem_max 1048576
可以將這幾個值都設為4k:
net.core.rmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_default = 4194304
net.core.wmem_max = 4194304
HP上:
請檢查UDP設定是否足夠大:
$ /bin/ndd -get /dev/sockets socket_udp_rcvbuf_default
$ /bin/ndd -get /dev/sockets socket_udp_sndbuf_default
確保socket_udp_rcvbuf_default至少是socket_udp_sndbuf_default的兩倍。
Sun:
可以用下面的命令檢視UDP設定:
ndd /dev/udp udp_xmit_hiwat
ndd /dev/udp udp_recv_hiwat
ndd /dev/udp udp_max_buf
可以用下面的命令設定這兩個值為OS最大允許的:
ndd -set /dev/udp udp_xmit_hiwat
ndd -set /dev/udp udp_recv_hiwat
ndd -set /dev/udp udp_max_buf <1M or higher>
更多資訊,可以參考MOS文件:
Tuning Inter-Instance Performance in RAC and OPS (Doc ID 181489.1)
第三步,檢視網路情況。
比如用netstat -s 命令檢視是否有bad data length, bad checksums, incomplete headers, socket buffer overflows等,注意這些值是累計的,需要檢視它們在發生問題的時候是否有增加。
另外可以檢視AWR中是否有 "Global Cache Blocks Lost" ,理想情況下這個值是0,如果有較大的block lost,說明網路有問題(按照MOS 文件563566.1進行網路檢查)。
還可以請網管檢視私網的效能情況。
第四步,檢查LMS。
1. 檢視LMS的trace file,檢視是否有異常。
2. 檢視LMS程式的優先順序是否是實時的(real time)的?
比如AIX:
# ps -elf|grep lms
ps -elf|grep lms
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
240103 A oracle 4719002 1 5 39 -- 8ae40b590 248856 Jul 28 - 570:45 ora_lms0_rac1
priority 越小說明優先順序越高,PRI小於40說明是Real Time的:
http://aix4admins.blogspot.co.uk/2011/08/commands-and-processes-process-you-use.html
3. 檢視LMS的個數:
SQL>show parameter GCS_SERVER_PROCESSES
這個值決定了LMS的個數
這個值依賴於CPU的個數(cpu_count),根據11.2官方文件:
Default value
If 1 - 3 CPUS, then 1
If 4 - 15 CPUs, then 2
If 16 or more CPUs, then 2 + (CPUs / 32). If the result includes a fraction, then the fraction is disregarded. For example, if you had 20 CPUs, then 2 + (20 / 32) would equal 2 GCS processes.
If CLUSTER_DATABASE is set to false, then 0
If ASM, then 1
在AIX上,有的時候CPU可能是動態增加的,那麼一定要注意檢查LMS程式的個數是否隨之調整了。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/25462274/viewspace-2141865/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 如何診斷RAC系統中的
- gc cr request等待事件GC事件
- 【等待事件】global cache cr request/gc current request事件GC
- gc cr request 'gcs log flush sync'GC
- gc current/cr block busy等待事件GCBloC事件
- RAC 環境中 gc block lost 和私網通訊效能問題的診斷 (文件 ID 1674865.1)GCBloC
- oracle 10.2.0.1 rac發現sql查詢hang之gc cr requestOracleSQLGC
- 【MOS】RAC 環境中 gc block lost 和私網通訊效能問題的診斷 (文件 ID 1674865.1)GCBloC
- 儲存過程遇到gc cr request等待儲存過程GC
- 分析解決11gR2 雙節點RAC環境下的gc cr block busy/gc buffer busy acquire等待GCBloCUI
- GC BUFFER BUSY問題的診斷GC
- win10系統如何禁用診斷工具Win10
- Win10系統下網路診斷在哪_win10系統如何使用網路診斷Win10
- GC機制和OutOfMemory問題的診斷GC
- 在Linux中,如何診斷和解決系統啟動問題?Linux
- RAC故障診斷指令碼指令碼
- 【故障診斷】cr塊slot notfound解決過程
- 整車EOL診斷系統
- 整車EOL 診斷系統
- ECS控制檯診斷系統
- 一次gc buffer busy問題的診斷GC
- RAC系統的問題診斷最佳實踐,及常見問題分析
- 【RAC】如何診斷RAC資料庫上的“IPC Send timeout”問題資料庫
- 診斷通用售後系統 — DGA
- gc current block pin time gc current block flush time 疑惑GCBloC
- 【RAC】Oracle Clusterware 診斷收集指令碼Oracle指令碼
- 如何診斷 Java 中的記憶體洩露Java記憶體洩露
- 如何診斷RAC資料庫上的“IPC Send timeout”問題?資料庫
- oracle RAC 診斷叢集狀態命令Oracle
- Oracle中診斷阻塞的sessionOracleSession
- 嵌入式系統除錯診斷方法除錯
- On AIX RAC中global cache cr rquest的的處理方法AI
- 收集Oracle RAC跟蹤診斷資訊的幾個工具Oracle
- 一次RAC單例項DOWN機的診斷單例
- windows10系統診斷策略服務未執行如何解決Windows
- Win10系統使用診斷模式後出現黑屏如何解決Win10模式
- 公司某資料子系統定期cpu過高的診斷
- 作業系統診斷工具truss, pstack, and pmap作業系統