MySQL 5.5版本注意大內存導致DDL變慢的問題
最近在協助用戶進行係統重構,RDS測試選型自然成為了本項目的一個重點,但是用戶在測試不同規格的時候發現大規格的實例性能居然不如小規格,4C32G規格性能比8C64G規格高出10%,其性能監控也是非常的正常,4C32G規格是8C64G規格資源消耗的一半,TPS也是相當,那問題到底出現在那裏?
CPU消耗對比:
TPS監控:
從監控上沒有看出端倪後,我們懷疑用戶的業務測試模型可能不一致,所以采取分析SQL審計日誌來分析問題,把top sql拿出來對比就可以一目了然問題的所在,所以重新開啟壓測,使用我們的專家分析係統來分析SQL日誌,結果讓人大吃所驚,一條truncate 語句映入眼:
可以看到truncate 語句在8C64G的規格中執行慢了30秒左右,這個時間恰好是整個測試相差的時間,為什麼規格越大反而DDL truncate越慢?這個問題其實在5.5版本存在的一個問題,可以參考在2015年雙11時候寫過的一篇文章:RDS彈性升級後性能反而下降的案例,所以解決方案隻要把實例升級到5.6就可以了。在這次問題排查中使用了很重要的SQL審計日誌來發現兩個實例規格的性能差異,該功能已經集成到RDS的專家係統中,幫助用戶更好的分析使用數據庫。
最後更新:2017-04-13 18:01:33