f Tuning Example IV: EDB(Postgres) DB 主機 CPU 滿載.....的案例 ~ 迪貝之家

Tuning Example IV: EDB(Postgres) DB 主機 CPU 滿載.....的案例

嘿...厲害吧~~~
我們家專門出現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該表
反正該講的我都講了
要怎麼做,那就不關我事了