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