雖然幹了很多SQl優化。 也寫博客記錄了很多, 但是貌似沒有記錄過系統整體優化的, 這次簡單記錄下吧。
景
XXB系統作爲核心的應用系統,具有涉及業務領域多,併發訪問量大,累計數據量大等特點。而且隨着市場的變化,尤其是在大數據環境下,數據增量明顯提高。而用戶對性能的要求也進一步提高,給系統性能優化帶來新的挑戰。
分析
在業務人員的大力度支持下,全面瞭解系統的業務特點,性能瓶頸。發現業務高峯期CPU負載壓力過高,一般業務高峯期50%左右,在“結算”“稽查”等業務合算過程中,CPU使用率超過 90%。也通過調查發現IO的吞吐量不高,才6M/S. IOPS也很小。進一步確定到系統壓力在邏輯讀上面。比如我們選取某一典型時間段CPU使用率以及邏輯讀數據曲線圖 .
業務高峯期AWR報告
TOP等待事件中“db file sequential read”最高, 該等待事件一般是和索引掃描(除了index fase full sacn),和索引回表造成的。 這種現象表示需要優化TOP SQL。
TOPSQl分析:(這裏只列出典型的三個)
SQL |
執行頻率 |
執行成本 |
5b3a7przhx4sc |
5萬次/半小時 |
2萬邏輯讀/次 |
55495fd93c886 |
4.4萬次/半小時 |
2.8萬邏輯讀/次 |
d0sd7kxr6ga47 |
8千次/半小時 |
4.7萬邏輯讀/次 |
對象分析:
和業務組大力度的交流中發現有些索引碎片非常嚴重,如下
索引 |
索引字段 |
索引體積 |
碎片程度 |
IDX_STU_O_ID |
STUD_ORDER_ID |
964M |
大約90%的碎片 |
INX_EXT_V_PARAM_ID |
PARAM_ID |
1376M |
大約90%的碎片 |
PK_ZMKM_ORDER_EXT_VAL |
EXT_VAL_ID |
2744M |
大約90%的碎片 |
INX_EXT_VAL |
EXT_VAL |
68M |
大約60%的碎片 |
實施
分別整理系統分析文檔,以及優化建議文檔,和業務組展開深入討論交流後決定實施優化。需要在業務低谷時間實施優化,實施過程中需要保障系統穩定的同時也要保證優化的平滑進行。
優化後:
業務高峯期整體表現:
|
優化前 |
優化後 |
CPU使用率 |
50%左右,偶爾90%+ |
12%左右,偶爾20%+ |
邏輯讀 |
150萬邏輯讀/S,偶爾250萬邏輯讀/S |
50萬邏輯讀/S,偶爾70+萬邏輯讀/S |
索引 |
索引字段 |
索引體積 |
重建後體積 |
IDX_STU_O_ID |
STUD_ORDER_ID |
964M |
20M |
INX_EXT_V_PARAM_ID |
PARAM_ID |
1376M |
104M |
PK_ZMKM_ORDER_EXT_VAL |
EXT_VAL_ID |
2744M |
168M |
INX_EXT_VAL |
EXT_VAL |
68M |
8M |
TOPSQl分析:
SQL |
執行頻率 |
優化前 |
優化後 |
5b3a7przhx4sc |
5萬次/半小時 |
2萬邏輯讀/次 |
3千邏輯讀/次,性能提升6倍 |
55495fd93c886 |
4.4萬次/半小時 |
2.8萬邏輯讀/次 |
7千邏輯讀/次,性能提升3倍 |
d0sd7kxr6ga47 |
8千次/半小時 |
4.7萬邏輯讀/次 |
3200邏輯讀/次,性能提升10倍 |