AWR中的時間模型
AWR是咱們進行Oracle性能調整的主要工具之一；通常狀況而言，時間是衡量性能好壞的一個重要指標，AWR中有不少與時間相關的內容和指標。先來看一下Oracle定義的響應時間公式：
Response time = Service time + Wait timehtml
服務時間(Service time)就是進程「真正」在cpu上運行的時間，能夠簡單理解爲AWR中的cpu time/db cpu，服務時間包括前臺進程(
Server process)和後臺進程(Backgroud process)消耗的時間。等待時間就是等待某種資源的時間耗費，好比等待鎖資源的耗費，能夠簡單對應爲awr中的wait time, 等待時間包括不少類型，通常最多見的是IO等待和併發等待,好比進程等待從物理磁盤讀取數據塊到內存中的等待。 Awr中的db time能夠簡單對應爲Response time；
l db time與cpu time
首先須要說明一個概念：時間片。現代操做系統(unix/Linux)將cpu資源劃分紅時間片(cpu slice)爲單位來使用，通常是一個很小的值，通常爲10ms。操做系統使用一個調度程序(好比linux的CFS調度器，來協調各個進程使用cpu資源。更詳細的內容超出了本文的討論範圍，有興趣的能夠參考操做系統相關的文檔。對於操做系統而言,一個進程要麼在cpu中運行，要麼處於等待隊列中；注意這裏的「等待」並不徹底等同於os中的等待。
DB time是整個數據庫用戶進程消耗的總時間，可用於衡量一個數據庫總體負載,這有一些相似unix/linux系統中的平均負載(average load)指標。咱們來看一份awr:
|
Snap Id
|
Snap Time
|
Sessions
|
Cursors/Session
|
|
|
Begin Snap:
|
9820
|
13-2月 -12 08:00:17前端 |
735
|
89.3
|
|
End Snap:
|
9821
|
13-2月 -12 09:00:13linux |
965
|
92.3
|
|
Elapsed:
|
59.93 (mins)
|
|||
|
DB Time:
|
437.53 (mins)
|
咱們能夠看到這一個awr的間隔時間爲60分鐘，而db time達到了437分鐘，比率大體爲7.3，咱們這一個系統爲16 core cpu 的小型機，那麼在60分鐘能夠提供的cpu time爲16*60=960分鐘的cpu time；若是咱們的db time所有都由cpu time來構成(固然是不可能的，Oracle總會有一些等待)，cpu的佔用率爲46%；cpu資源仍是足夠的；考慮到db time還包括一部分wait time,咱們的cpu佔用率會遠遠低於46%。
Db time主要用於對比同一系統的不一樣時段，或同一時段的不一樣系統來獲得總體負載的初步映象，對比法是性能調整中，屢試不爽的重要法門！
|
Snap Id
|
Snap Time
|
Sessions
|
Cursors/Session
|
|
|
Begin Snap:
|
571
|
31-May-10 08:00:16
|
472
|
56.9
|
|
End Snap:
|
572
|
31-May-10 09:00:17
|
307
|
50.1
|
|
Elapsed:
|
60.02 (mins)
|
|||
|
DB Time:
|
1,139.42 (mins)
|
這一樣是一個16 core的系統，不一樣醫院同一時段的系統，咱們能夠看到在會話數(sessions)與每一個會話的平均cursor數量(Cursors/Session)都小於前一個系統的狀況下(能夠簡單的理解爲醫院的規模和應用範圍都小於前一個系統)，db time大幅增長；總的db time達到了1139分鐘，據此咱們初步認爲從總體來看第二個系統的性能是比較差的。
接下來咱們來討論一下cpu time，cpu time在awr中也表示爲db cpu，同時cpu time也是一個空閒等待事件，但這三者沒有太大區別，時間值也是相同的。cpu time是Oracle對操做系統而言真正意義上的cpu消耗。那如何計算一個Oracle實例對操做系統的時間佔比呢？很簡單,公式以下:
Cpu time/ (Elapsed time * CPU cores)sql
在AWR中的top 5 waits或Time Model Statistics均可以找到 cpu time:
|
Event
|
Waits
|
Time(s)
|
Avg Wait(ms)
|
% Total Call Time
|
Wait Class
|
|
latch: cache buffers chains
|
76,560
|
33,283
|
435
|
48.7
|
Concurrency
|
|
CPU time
|
23,129
|
33.8
|
|||
|
log file sync
|
28,057
|
2,754
|
98
|
4.0
|
Commit
|
|
db file sequential read
|
312,477
|
2,169
|
7
|
3.2
|
User I/O
|
|
log file parallel write
|
24,580
|
633
|
26
|
.9
|
System I/O
|
l Time Model Statistics
在awr中，Time Model Statistics用於回答「到底前臺進程消耗了多少時間?」，「語句解析消耗了多少時間?」等諸如此類的問題,咱們來看一個例子：數據庫
|
Statistic Name
|
Time (s)
|
% of DB Time
|
|
connection management call elapsed time
|
21,708.46
|
15.22
|
|
sql execute elapsed time
|
21,596.44
|
15.14
|
|
parse time elapsed
|
17,648.50
|
12.37
|
|
hard parse elapsed time
|
9,081.89
|
6.37
|
|
hard parse (sharing criteria) elapsed time
|
4,158.48
|
2.92
|
|
hard parse (bind mismatch) elapsed time
|
3,189.62
|
2.24
|
|
PL/SQL execution elapsed time
|
2,362.21
|
1.66
|
|
DB CPU
|
2,311.28
|
1.62
|
|
PL/SQL compilation elapsed time
|
145.25
|
0.10
|
|
failed parse elapsed time
|
89.78
|
0.06
|
|
sequence load elapsed time
|
69.16
|
0.05
|
|
repeated bind elapsed time
|
0.21
|
0.00
|
|
DB time
|
142,622.31
|
|
|
background elapsed time
|
4,871.65
|
|
|
background cpu time
|
22.41
|
咱們看到，真於用於sql執行的時間(sql execute elapsed time)只佔到了15.14%;這個比率是很是低的，做來一個相對正常的系統，這一比率不該低於90%甚至更高!咱們看到用於鏈接管理(connection management call elapsed time)的時間爲15%,用於sql解析(parse time elapsed)的時爲12.37%，且其中硬解析sql(hard parse elapsed time)的時間爲6.37%。從這幾個方面來看，咱們能夠做一些合理的推測：緩存
1. 系統是否存在頻繁鏈接和斷開鏈接的狀況?若是存在這種狀況，是不是網絡不穩定，或者監聽程序存在問題形成了這個狀況？還有就是中間件到數據庫服務器的鏈接池是否出了問題？
2. Sql語句解析不合理;這是否由於共享池設置太小？應用程序是否未使用綁定變量?仍是由於開啓了SGA自動管理，帶來了嚴重的內存顛簸現象？
能夠看到，經過對時間模型的分析，能夠幫助咱們結合等待事件、latch信息等內容而對性能問題做出更爲準確的判斷。
4、操做系統相關的信息
Awr中也採集了部分操做系統的信息，特別是到了11g，更進一步的幫咱們計算出了cpu佔用率，很是方便; awr中的Operating System Statistics部分：
|
NUM_LCPUS
|
0
|
|
NUM_VCPUS
|
0
|
|
AVG_BUSY_TIME
|
149,127
|
|
AVG_IDLE_TIME
|
211,742
|
|
AVG_IOWAIT_TIME
|
40,260
|
|
AVG_SYS_TIME
|
14,015
|
|
AVG_USER_TIME
|
135,004
|
|
BUSY_TIME
|
2,387,903
|
|
IDLE_TIME
|
3,389,758
|
|
IOWAIT_TIME
|
646,085
|
|
SYS_TIME
|
225,900
|
|
USER_TIME
|
2,162,003
|
|
LOAD
|
0
|
|
OS_CPU_WAIT_TIME
|
2,474,600
|
|
RSRC_MGR_CPU_WAIT_TIME
|
0
|
|
PHYSICAL_MEMORY_BYTES
|
49,123,688,448
|
|
NUM_CPUS
|
16
|
|
NUM_CPU_CORES
|
8
|
從圖中，咱們能夠獲得cpu數量、busy_time、idle_time、iowait_time、物理內存等信息，對於咱們瞭解系統級的性能信息頗有幫助。好比我能夠透過以下公式來計算awr採集期間的平均cpu佔用率：
BUSY_TIME/( BUSY_TIME+ IDLE_TIME) * 100%
具體到咱們的例子，2,387,903/(2,387,903+3,389,758)*100%=41.33%。固然這裏的cpu佔用率，是從操做系統層面來看的，並非Oracle實例的cpu佔用狀況，由於主機能夠運行了其餘Oracle實例、或者中間件之類的其餘軟件系統。同時，咱們也能夠經過IOWAIT_TIME來初步判斷咱們的系統是否存在io瓶頸。
l 5、多關注平均時間
「平均」是一個頗有意思的話題，你們對平均的最直觀的感覺就是統計局發佈「XX地區平均收入已經突破XX元」，不少人都會發出「拖偉大祖國的後腿了！」這樣的感嘆。根據平均理論：即便咱們的頭被火燒，腳浸泡在冰水裏，也不會感到難受！這種狀況在AWR的分析中也是須要注意的。
Awr採集的是一段時間總體性能數據，可能平均數據看起來沒有問題，但前端用戶可能仍是感受慢,由於某些次數的長時間等待被其餘較短期的等待給「平均」掉了！這就須要咱們區別不一樣的類型的問題，可能這些問題並不適合awr來診斷，而應該選用更合適的ash、sql trace等工具進行診斷。但這並說明「平均」的時間沒有任何價值，只是須要具體問題具體分析。
咱們這裏談一下等待事件的平均等待時間:
Top 5 Timed Events
|
Event
|
Waits
|
Time(s)
|
Avg Wait(ms)
|
% Total Call Time
|
Wait Class
|
|
CPU time
|
17,217
|
54.5
|
|||
|
db file sequential read
|
1,155,423
|
8,422
|
7
|
26.6
|
User I/O
|
|
db file scattered read
|
30,541
|
660
|
22
|
2.1
|
User I/O
|
|
gc current block 2-way
|
900,865
|
538
|
1
|
1.7
|
Cluster
|
|
gc cr grant 2-way
|
467,627
|
244
|
1
|
.8
|
Cluster
|
對於IO類型的等待事件來講，好比常見的db file sequential read平均等待時間通常不要超過10ms,這是根據當前硬盤的機械結構、轉速等得出的一個經驗值，由於單塊10000轉的普通磁盤，尋道時間在7-10ms左右。固然,若是考慮存儲緩存、文件系統緩存、IO大小等狀況，這個值通常在4-7ms之間;同時必須是IO系統在正常的iops（每秒的io次數，用於衡量存儲併發吞量）下才有意義。若是超過經驗值不少，就要分析具體的緣由了，多是存儲的緩存功能沒有啓用、raid組中的磁盤損壞、不合理的raid級別等各類緣由;固然也有多是系統io負載過大，存儲的負擔較重，若是是這種狀況就須要給合應用的io量(物理讀與邏輯讀)，特別是sql的io狀況來分析了。服務器
咱們再來看一個真實的案例：
Top 5 Timed Foreground Events
|
Event
|
Waits
|
Time(s)
|
Avg wait (ms)
|
% DB time
|
Wait Class
|
|
db file sequential read
|
561,555
|
37,163
|
66
|
34.73
|
User I/O
|
|
read by other session
|
405,945
|
20,251
|
50
|
18.92
|
User I/O
|
|
log file sync
|
30,655
|
15,101
|
493
|
14.11
|
Commit
|
|
direct path read
|
171,963
|
12,254
|
71
|
11.45
|
User I/O
|
|
DB CPU
|
9,907
|
9.26
|
咱們看到整個系統的等待事件主要集中在IO上。db file sequential read的平均等待時間爲66ms，而log file sync達到了驚人的493ms，也就是近0.5秒。log file sync通常由事務提交引發，也就是說一個事務光在提交上，就須要花費0.5s！請記住，這仍是一個平均數，還有不少事務，是遠遠大於這個時間的！最終檢查出來的緣由是醫院的存儲使用了7200轉的sata硬盤構建的RAID5,這樣的配置對於ZLHIS這樣的oltp系統來講，無疑就是災難！
l 也說一下次數
前面談的都是「時間」，下面咱們來談一下次數，同時做爲本文的結束。首先，一些latch相關的等待事件，與latch中的sleep的次數相一致！好比library cache lock/pin、latch:shared pool等。好比：網絡
|
Event
|
Waits
|
%Time -outssession |
Total Wait Time (s)架構 |
Avg wait (ms) |
Waits /txn |
| rdbms ipc reply |
1,622
|
0.00
|
1
|
0
|
0.05
|
| latch: cache buffers chains |
3,941
|
0.00
|
1
|
0
|
0.12
|
這裏咱們能夠看到,等待事件latch: cache buffers chains的等待次數爲3941次，相應的latch統計信息以下：
| Latch Name |
Get Requests |
Misses
|
Sleeps
|
Spin Gets |
Sleep1
|
Sleep2
|
Sleep3
|
| cache buffers chains |
3,686,756,120
|
7,504,592
|
3,941
|
7,505,392
|
0
|
0
|
能夠看到二者確實是相等的，也就是說只有latch獲取過程當中，sleep的操做纔會產生一次對應的等待事件。
最後仍是回到咱們的時間模型上來,若是咱們的系統只運行了一個數據庫實例，則cpu time與busy time扣除io wait time後，應該是基本一致,來看一下案例:
Top 5 Timed Events
|
Event
|
Waits
|
Time(s)
|
Avg Wait(ms) |
% Total Call Time |
Wait Class |
| CPU time |
|
17,217
|
|
54.5
|
|
| db file sequential read |
1,155,423
|
8,422
|
7
|
26.6
|
User I/O |
| db file scattered read |
30,541
|
660
|
22
|
2.1
|
User I/O |
| gc current block 2-way |
900,865
|
538
|
1
|
1.7
|
Cluster
|
| gc cr grant 2-way |
467,627
|
244
|
1
|
.8
|
Cluster
|
Operating System Statistics
|
Statistic
|
Total
|
|
NUM_LCPUS
|
0
|
|
NUM_VCPUS
|
0
|
|
AVG_BUSY_TIME
|
149,127
|
|
AVG_IDLE_TIME
|
211,742
|
|
AVG_IOWAIT_TIME
|
40,260
|
|
AVG_SYS_TIME
|
14,015
|
|
AVG_USER_TIME
|
135,004
|
|
BUSY_TIME
|
2,387,903
|
|
IDLE_TIME
|
3,389,758
|
|
IOWAIT_TIME
|
646,085
|
|
SYS_TIME
|
225,900
|
|
USER_TIME
|
2,162,003
|
|
LOAD
|
0
|
|
OS_CPU_WAIT_TIME
|
2,474,600
|
|
RSRC_MGR_CPU_WAIT_TIME
|
0
|
|
PHYSICAL_MEMORY_BYTES
|
49,123,688,448
|
|
NUM_CPUS
|
16
|
|
NUM_CPU_CORES
|
8
|
cpu time爲17,217s,也就是17,217000ms;
busy_time-iowait_time爲:1741818ms(387,903-646,085)
能夠看到二者基本相近;若是二者相差過大，就表示服務器上可能運行了其餘程序或者其餘的Oracle實例。
7、RAC性能
若是使用了RAC架構，須要特別關注RAC相關的時間要素,仍是經過一個案例來講明：
|
Avg global enqueue get time (ms):
|
2.5
|
|
Avg global cache cr block receive time (ms):
|
172.2
|
|
Avg global cache current block receive time (ms):
|
6.6
|
|
Avg global cache cr block build time (ms):
|
0.0
|
|
Avg global cache cr block send time (ms):
|
0.0
|
|
Global cache log flushes for cr blocks served %:
|
13.6
|
|
Avg global cache cr block flush time (ms):
|
0.8
|
|
Avg global cache current block pin time (ms):
|
0.2
|
|
Avg global cache current block send time (ms):
|
0.0
|
|
Global cache log flushes for current blocks served %:
|
0.3
|
|
Avg global cache current block flush time (ms):
|
3.2
|
這些值的官方數字從幾ms到10ms不等，但咱們這裏的Avg global cache cr block receive time (ms)達到了驚人的172.2ms，這個指標表示，Oracle實例接收全局的CR塊(一致性讀數據塊)的平均時間，這表示RAC中，各個節點間的熱塊急用是至關嚴重，須要在底層打散IO或者調整應用，減小總的IO量，並下降各個節點訪問相同數據塊的機率。具體的打散IO熱點的技術，請參照其餘文檔。
8、總結
最後須要說起一點的就是awr中使用「時間」對SQL做出較多的分類，以便於咱們找到消耗某類」時間」最多的sql語句，主要包括：
好比，咱們能夠經過SQL ordered by Elapsed Time來找到執行時間最慢的sql,經過SQL ordered by CPU Time最消耗cpu的sql等等。
還有就是IO部分，awr也提供了表空間與數據文件的io響應時間，也對於咱們分散IO熱點區域，在存儲底層進行性能調整提供了有價值的參考。
透過前面對awr時間模型的討論，咱們能夠看到awr提供給咱們的不少數據，之間有很是緊密的聯繫；這就要求咱們在對awr做分析時，不能孤立的看待某些指標，須要結合不一樣的內容來相互映證，同時結合應用的特色、環境變動、硬件條件等方面來做出正確的判斷。
相關文章
- 1. Flink---時間模型
- 2. Python中的ARIMA模型、SARIMA模型和SARIMAX模型對時間序列預測
- 3. 算法模型---時間序列模型
- 4. 時間序列模型（ARIMA模型）
- 5. python 中的時間模塊
- 6. python中的時間模塊
- 7. day6：時間序列模型
- 8. 時間序列ARIMA模型
- 9. Task03：時間序列模型
- 10. 時間管理模型
- 更多相關文章...
- • SQLite 日期 & 時間 - SQLite教程
- • XSD 日期和時間數據類型 - XML Schema 教程
- • 委託模式
- • C# 中 foreach 遍歷的用法
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. Flink---時間模型
- 2. Python中的ARIMA模型、SARIMA模型和SARIMAX模型對時間序列預測
- 3. 算法模型---時間序列模型
- 4. 時間序列模型（ARIMA模型）
- 5. python 中的時間模塊
- 6. python中的時間模塊
- 7. day6：時間序列模型
- 8. 時間序列ARIMA模型
- 9. Task03：時間序列模型
- 10. 時間管理模型