嘿...厲害吧~~~ |
我們家專門出現CPU滿載的案例 |
出現的狀況是 |
系統是由士林clone至板橋 |
莫名其妙板橋晚上6點鐘開始就CPU衝高 |
有人來反應 |
我也就只能查看數據 |
這系統很舊了...9.1 PPAS |
Postgres當然就是看pgbager報表 |
不然哩.... |
能不透過工具就能debug postgres 效能的人 |
我佩服你..... |
首先當然看數據 |
應該是這兩段sql 語句造成 |
再比對同時段另一個運作正常的資料庫的數據 |
很明顯吧~~ |
總執行1個多小時分別跟13分鐘及1.5秒做比較 |
比對Min/Max/Avg duration (s)這個欄位的最右邊的值(平均值)就可以看得出來最大的差異應該是在執行速度 |
通常看到這個狀況 |
大概就是去看執行計畫了 |
恩.... |
還真的不一樣 |
原以為找到原因了 |
後來我用sql hint去指定跑速正常的索引 |
(不要懷疑, edb 真的有這個功能) |
(對...就是Oracle的語法) |
執行計畫一樣了.... |
但........ |
沒有改善..... |
我就知道,應該不是root cause |
就再找過.... |
因此就去比對兩邊的表格大小 |
看到了吧~~ |
408K VS 1827M |
這就難怪囉...... |
然後去count兩邊的筆數 |
當下都是0筆 |
所以我就建議用truncate指令把表格縮小 |
指令下完後 |
當晚CPU就沒衝高了 |
想說...總算呈現了我的價值吧~~ |
隔沒幾天 |
同個人又反應晚上CPU衝高 |
其實之前每天日檢的時候 |
我就發現報表裏頭有drop 指令出現 |
其實那時候我應該有發mail出去 |
但沒人回應我 |
那就算了.... |
憑我的印象,我就用drop 字眼去掃兩端的系統記錄檔 |
截圖後把它mail出去 |
每天中午一點會有個排程drop該表 |
反正該講的我都講了 |
要怎麼做,那就不關我事了 |