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