f Tuning Example II: SQL Server CPU 滿載.....的案例 ~ 迪貝之家

Pages

Tuning Example II: SQL Server CPU 滿載.....的案例

這個案例...我不得不說
其實有點烏龍

話說...晚上11點突然接到電話
CPU衝高,然後跟我要LOCK的資料
所以我就給了LOCK資料
很晚了,我也懶得動腦了,你要什麼,我就給你什麼!!
從資料上看起來
SESSION ID 92 卡住了 1450
1450卡住了 1911
這3個SESSION就影響了共
5 + 20 + 19 = 44
個SESSION
當然後來就又談怎麼砍SESSION
我也就只能..好....
幫你砍......
處理完凌晨一點了
危機暫時解除了.........
但隔天上班10點快11點又發生同樣的狀況了
CPU又再次衝高了
還被使用者在臉書上抱怨...
處理方法還是老招...砍session
後來砍到實在有夠煩的
我就說....我都砍了幾百個session了
資料庫的連線還一直衝了進來
可不可以重開AP Server
還真的重開了.....
不過沒解決問題.....
這次我就仔細看了whoisactive的資料
看了login_name我就問了
這個帳號我認為是那種每5分鐘跑批次帳號
為什麼會連進這麼多個session
AP回答我....Online及批次都是這個帳號執行程式
我當下恍然大悟...cow~~取個名字都能造成我的誤會
從我用紅色圈起來的執行時間都是將近30秒
是誰用手機app時,點一個畫面會有那個耐心等你30秒
我想大家都是點一點沒回應
就接著就繼續點...就趴趴趴趴...session就一直衝進來
資料庫連線就因為前個session還沒處理完需求
後續的session就累積上去
就這樣把系統的CPU資源全吃光了
所以變成是sql 語句的執行效率問題
想到這裡,我就點進plan欄位,去看執行計畫
該plan就給了建立include index的建議
中午休息時間
同仁關掉AP Server
建出該索引
系統重開後就解決了
你看...是不是一場烏龍
我想說...批次程式跑個30秒,應該正常吧!!
就沒往下看了...
誰知它是online operation所使用的帳號

隔天上班,我就收集了前一天的數據給AP
這應該是每5分鐘的批次運作