MySQL大事務導致的Insert慢的案例分析
【問題】
有臺SQL/">MySQL伺服器不定時的會出現併發執行緒的告警,從記錄資訊來看,有大量insert的慢查詢,執行幾十秒,等待flushing log,狀態query end
【初步分析】
從等待資源來看,大部分時間消耗在了innodb_log_file階段,懷疑可能是磁碟問題導致,經過排查沒有發現伺服器本身存在硬體問題
後面開啟執行緒上升時pstack的自動採集,定位MySQL執行緒等待的位置。
【分析過程】
部署了pstack的自動抓取後,出現過6次thread concurrency >=50的告警(每次告警時會有大量的慢查詢產生),有3次抓到了現場。
併發執行緒升高時,有50多個執行緒卡在Stage_manager::enroll_for函式,處於group commit階段
執行緒0x519c5940對應的SQL語句如下,已經執行18秒
Stage_manager::enroll_for函式的作用實現了多個執行緒在flush_stage階段的排隊。簡單來說,對於一個分組的事務,是被leader執行緒去提交的,其他執行緒處於排隊等待狀態,等待leader執行緒將該執行緒的事務提交完成。
如果第一個執行緒執行慢,後面的執行緒都處於等待狀態,整組事務無法提交。
流程也可以理解如下,
Session A COMMIT-->拿到鎖-->進行binlog寫-->commit完成
Session B COMMIT-->等待鎖--------------------------->拿到鎖-->進行binlog寫-->commit完成
第一個執行緒為什麼執行很慢,分析了發生告警時間段的日誌檔案,發現日誌中存在2個15M和20M的大事務
檢視日誌明細,存在delete from的大事務刪除語句,約包含23W條記錄,ROW模式下刪除23W條記錄,會產生大約20M的日誌檔案,刷盤時間較長,阻塞了同一個分組下其他事務的提交。
事務的開始時間與告警時間吻合
積壓的分組下事務集中刷盤,反應到磁碟指標上可以看到在問題時間段的disk_write_kbytes指標出現明顯的上升
【優化方案】
1、 建議開發避免使用delete from 整表的大事務刪除語句
【其他變通方案】
2、 Binlog 記錄的ROW模式下會產生大量的日誌,改為MIXED模式,理論上也可以解決問題
3、 更換效能好的磁碟
Linux公社的RSS地址 : ofollow,noindex" target="_blank">https://www.linuxidc.com/rssFeed.aspx
本文永久更新連結地址: https://www.linuxidc.com/Linux/2018-10/154980.htm