與IO相關的等待事件troubleshooting-系列2

bisal發表於2013-10-04
事件

Troubleshooting步驟：

Troubleshooting與IO相關的等待：

資料庫效能調優方面一項關鍵的方法就是響應時間分析。找出時間都花費在資料庫的哪些環節。

時間是效能調優中最重要的屬性。使用者通過交易或批處理任務的響應時間來感知系統的效能。

Oracle的響應時間分析使用如下公式：

Response Time = Service Time + Wait Time

響應時間=服務處理時間+等待時間

‘服務處理時間’使用‘CPU used by this session’統計資料來衡量。

‘等待時間’則是所有等待事件用時之和。

注：儘管很像，但這個公式絕對不是排隊理論的基礎公式。

通過分析總體響應時間不同元件的相對影響，可以使用AWR或statspack這樣的工具進行效能調優，將調優的精力放到最消耗時間的元件中。


判斷IO等待事件的真實重要性：

        包括AWR和Statspack在內的許多工具都可以列出最重要的等待事件。Oracle 9i R2的Statspack報告之前的版本包含在了"Top 5 Wait Events"節。

        當看到這樣的top等待事件列表，通常就會很容易地開始處理這些等待事件，但往往忽視了首先可以分析下他們對總體響應時間的影響。

        “Service Time”(例如CPU的使用)要遠比“Wait Time”更重要，分析這些等待事件不會對節省“響應時間”有幫助。

        因此，應該將top等待事件花費的時間與“CPU used by this session”對比，將調優的精力放到最需要的地方。

        從Oracle 9i R2開始，“Top 5 Wait Events”已經改名為“Top 5 Timed Events”，通過統計session所用的CPU來衡量“Service Time”，並列到“CPU time”中。這就意味著可以更容易、更準確地衡量等待事件對總體“響應時間”的影響，正確地指導接下來的調優方向。


錯誤理解等待事件的影響：例項

        接下來的兩個真實案例說明了為什麼需要檢視“Wait Time”和"Service Time"兩部分，對分析資料庫效能的重要性。

例項1：Oracle 9i R2之前的Statspack

        下面是產生自46分鐘的兩個snapshot之間的Statspack報告“Top 5 Wait Events”節：

Top 5 Wait Events                                                             
~~~~~~~~~~~~~~~~~                                             Wait     % Total
Event                                               Waits  Time (cs)   Wt Time
-------------------------------------------- ------------ ------------ -------
direct path read                                    4,232       10,827   52.01
db file scattered read                              6,105        6,264   30.09
direct path write                                   1,992        3,268   15.70
control file parallel write                           893          198     .95
db file parallel write                                 40          131     .63
         -------------------------------------------------------------

        從以上的列表，我們很可能傾向於立即開始查詢“direct path read”和“db file scattered read”等待之間的原因，嘗試調優他們。這種方法沒有考慮到“Service Time”。

        從同一份報告中得到的“Service Time”如下：

Statistic                                    Total   per Second    per Trans  
--------------------------------- ---------------- ------------ ------------  
CPU used by this session                   358,806        130.5     12,372.6

        讓我們來做一下簡單的計算：

'Wait Time' = 10,827 x 100% / 52,01% = 20,817 cs

'Service Time' = 358,806 cs

'Response Time' = 358,806 + 20,817 = 379,623 cs

        如果現在我們來計算所有“Response Time”元件的百分比：

CPU time                    = 94.52%
direct path read            =  2.85%
db file scattered read      =  1.65%
direct path write           =  0.86%
control file parallel write =  0.05%
db file parallel write      =  0.03%

        現在就明顯了，與IO相關的等待事件對於總體響應時間來說並不是真正耗時的元件(少於6%)，因此解析來的調優應該聚焦在服務處理時間元件上，例如CPU消耗。


例項2：Oracle 10i R2之後的AWR

注意：類似的資訊也會顯示在Oracle 9i R2以後的Statspack報告：

Top 5 Timed Foreground Events 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
                                                          Avg  
                                                         wait   % DB 
Event                                 Waits     Time(s)   (ms)   time Wait Class 
------------------------------ ------------ ----------- ------ ------ ----------
DB CPU                                           33,615          82.0           
db file sequential read           3,101,013       7,359      2   18.0 User I/O  
log file sync                       472,958         484      1    1.2 Commit    
read by other session                46,134         291      6     .7 User I/O  
db file parallel read                91,982         257      3     .6 User I/O

        在AWR中，更容易看到CPU是最耗費時間的，因為CPU元件也包括在“Top 5 Timed Foreground Events”節。從上面的例子，我們能夠再次看到等待事件的用時少於20%，家下來的調優重點應該放在服務處理時間的元件上，例如CPU消耗。


(未完待續)

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7192724/viewspace-773728/，如需轉載，請註明出處，否則將追究法律責任。

相關文章