這個案例...我不得不說 |
其實有點烏龍 |
話說...晚上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分鐘的批次運作 |