MySQL服務器 IO 100%的案例分析


【問題】

有台MySQL 5.6.21的數據庫實例以寫入為主,IO %util接近100%

 

寫入IOPS很高

 

【分析過程】

1、通過iotop工具可以看到當前IO消耗最高的mysql線程

 

2、查看線程49342的堆棧,可以看到正在進行redo log的刷新,對應的是9號文件

 

3、9號文件對應的是redo log的第一個文件

 

為什么mysql進程會頻繁的刷新redo log文件,要結合redolog的刷盤策略來分析,關鍵是innodb_flush_log_at_trx_commit參數,

默認是1,最安全,但在寫壓力大的情況下,也會帶來較大的性能影響,每次事務提交時MySQL都會把log buffer的數據寫入log file,並且flush(刷到磁盤)中去。

 結合這個集群的寫入場景來看,大部分都是小事務的寫入,每次事務提交都會觸發刷盤動作,這種場景下通過增大innodb_log_buffer_size和innodb_log_file_size的優化效果不明顯

 

【優化方案】

1、應用層面,對於寫壓力大的系統,可以將單條的insert語句優化為小批量的insert語句,這樣事務commit的次數減少,redo log刷盤減少,性能理論上會有提升

2、MySQL層面,對於日志類型的系統,如果允許宕機的情況下少量數據丟失,可以將innodb_flush_log_at_trx_commit參數調整為2,

當設置為2時,則在事務提交時只做write操作,只保證寫到系統的page cache,因此實例crash不會丟失事務,但宕機則可能丟失事務

在這台服務器上測試,將參數調整為2時,IO的請求從200M/S降到約10M/S壓力會減少10倍以上

3、系統層面,更換性能更佳的磁盤

 

 獲取更及時的文章信息,請關注我的微信公眾號

 

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM