[異常等待事件rdbms ipc reply]-分析說明

rdbms ipc reply 等待嚴重，資料庫整體效能下降

 

2013 年 2 月 2 號 12:40 至 13:00 ，客戶前臺業務操作比較緩慢。 資料庫 1 號節點 CPU 資源比較緊張，使用率在 90% 以上，同時 1 號節點也出現了比較多的 rdbms ipc reply 等待事件。

          對 客戶 業務系統執行進行綜合判斷之後，基本確認為在混合批處理環境下的業務高併發導致，業務執行是相對緩慢而不是無法繼續。在無法確認應用是否變化的前提下，基本可以排除應用程式原因。綜合來看，導致本次業務執行緩慢的主要原因有以下幾點：

l   1 號節點 CPU 負載過高，使用率達到了 95% 左右。

l   1 號節點高併發環境的軟解析指標過高，每秒鐘達到了 8500 次左右，而 2 號節點每秒鐘只有 2300 次左右，負載不均衡。

l   軟解析過高導致 RAC 後臺程式 lck 壓力過大。 lck 程式主要用於傳遞 library cache 和 row cache 之間的資源。而 CPU 負載過高又會導致 lck 程式無法獲得 CPU 時間片，進而導致 lck 出現等待。

l   Bug 10314582 。該 BUG 在 Oracle 11.2.0.3 修復。        

2013 年 2 月 2 日 13 點左右 客戶 資料庫 1 號節點主機 CPU 資源比較緊張，使用率高達 95% 以上，如下所示：

同時 1 號節點出現瞭如下等待事件，其中 rdbms ipc reply 等待事件居於首位，每次等待時間高達 118ms ，如下所示：

進一步透過檢視 ASH 報告，發現該等待事件主要由 lck 程式引起， 44 號表示 lck 程式 , 如下所示：

等待 rdbms ipc reply 的 SQL 語句為 ggw0k4vu2q9yc ：

該 SQL 語句執行頻率非常之高，每秒鐘高達 183 次：

lck 程式的主要作用是協調非 Cache Fusion 資源（ Cache Fusion 資源主要指的是資料塊，由 lms 程式負責傳輸），如協調 library cache 和 row cache 中的資源。當系統的 CPU 資源比較緊張的時候， lck 程式可能會由於獲得不了 CPU 時間片，而導致協調資源效率低下。而故障期間 1 號節點的軟解析次數高達 8382 次，進一步加劇了 lck 程式的繁忙程度，如下所示：

根據客戶反饋，故障期間 lck 程式主要等待 css group membership query 等待事件，該等待事件就是協調節點間的資源。

查詢 MOS ，發現類似 BUG ，該 BUG 在 11.2.0.3 中已經修復， MOS DOC ID 如下所示：

Bug 10314582 - "rdbms ipc reply" waits when parsing in RAC (Doc ID 10314582.8)

（ 1 ）、增加 SESSION_CACHED_CURSORS 的值來緩解一下軟解析高的問題，目前改值為 300 ，調整到 500 。

（ 2 ）、確認 sqlid 為 ggw0k4vu2q9yc 執行如此頻繁的原因，降低 CPU 消耗。

（ 3 ）、確認雙節點業務負載不均衡原因， 1 號節點軟解析高達 8500 左右，而二號節點只有 2500 左右。

（ 3 ）、 CRM 升級至 11.2.0.3.5 。