最近幾天對客戶的一個核心數(shù)據(jù)庫進(jìn)行了優(yōu)化，將資源消耗較高的SQL優(yōu)化完成之后，物理讀和邏輯讀總量得到了降低。客戶反饋優(yōu)化后性能有提升，但仍然在某些工作日的業(yè)務(wù)高峰時段存在性能問題。 我們通過將性能不佳的業(yè)務(wù)高峰時段（即問題時段）與性能正常的業(yè)務(wù)

最近幾天對客戶的一個核心數(shù)據(jù)庫進(jìn)行了優(yōu)化，將資源消耗較高的SQL優(yōu)化完成之后，物理讀和邏輯讀總量得到了降低。客戶反饋優(yōu)化后性能有提升，但仍然在某些工作日的業(yè)務(wù)高峰時段存在性能問題。
我們通過將性能不佳的業(yè)務(wù)高峰時段（即問題時段）與性能正常的業(yè)務(wù)高峰時段（即基線時段）的性能數(shù)據(jù)進(jìn)行了對比，發(fā)現(xiàn)了一些問題：

基線時段為2014-1-15日上午8:00-上午9:00，此時段TPS（每秒事務(wù)量）為：46T/s，該時段的總DB Time為：626.2 (mins)

問題時段為2014-1-20日上午8:00-上午9:00，此時段TPS為：47T/s（僅比基線時段多1T/s，可認(rèn)為兩者業(yè)務(wù)量相當(dāng)），該時段的總DB Time為2361.4 (mins)

同樣均為1小時的取樣時間段，問題段的總DB Time是基線的近4倍，而通過對比兩者的性能視圖，發(fā)現(xiàn)問題時段的單次IO延遲非常高，如下：
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
DB CPU 2,082 55.42
db file sequential read 62,140 774 12 20.61 User I/O
direct path read 177,440 575 3 15.31 User I/O
log file sync 17,486 145 8 3.86 Commit
gc cr block 2-way 98,519 30 0 0.80 Cluster

基線時段單次序列讀延時為12ms,單次直接讀延時為3ms，單次redolog寫延時為8ms，

Event Waits Time(s) Avg wait (ms) % DB time Wait Class
direct path read 180,200 4,643 26 32.77 User I/O
db file sequential read 55,483 2,286 41 16.13 User I/O
DB CPU 1,917 13.53
gc buffer busy acquire 5,513 1,474 267 10.40 Cluster
log file sync 17,541 1,298 74 9.16 Commit

而問題時段單次序列讀延時為41ms,單次直接讀延時為26ms，單次redolog寫延時為74ms
（Oracle文檔中建議的單次IO正常延時應(yīng)為0-20ms，否則需升級硬件），
即相比基線時段，在業(yè)務(wù)量不變的情況下，問題時段的IO效率下降非常明顯，懷疑是存儲層面的同一個RAID組中有其他業(yè)務(wù)系統(tǒng)有可能恰好在問題時段有大量的IO操作，
導(dǎo)致我們正在優(yōu)化的系統(tǒng)的IO延遲較大。跟客戶的存儲人員確認(rèn)發(fā)現(xiàn)確實如此，存儲人員并沒有結(jié)合數(shù)據(jù)庫對存儲做出合理規(guī)劃，僅僅從容量管理上對自己工作的方便性出發(fā)，劃分并分配LUN。由此導(dǎo)致性能問題，我想這種問題在很多企業(yè)都是存在的，跨部門之間的溝通不暢導(dǎo)致沒有從整體上的規(guī)劃出現(xiàn)，最終出現(xiàn)問題由DB買單。

因此建議客戶進(jìn)行存儲改善：
1.將這種關(guān)鍵系統(tǒng)在存儲層面與其他系統(tǒng)隔離，避免互相影響IO；
2.有預(yù)算的情況下升級存儲。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com