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

【問題】

有臺MySQL 5.6.21的數據庫實例以寫入爲主，IO %util接近100%

 

寫入IOPS很高

 

【分析過程】

一、經過iotop工具能夠看到當前IO消耗最高的mysql線程

 

二、查看線程49342的堆棧，能夠看到正在進行redo log的刷新，對應的是9號文件

 

三、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的優化效果不明顯

 

【優化方案】

一、應用層面，對於寫壓力大的系統，能夠將單條的insert語句優化爲小批量的insert語句，這樣事務commit的次數減小，redo log刷盤減小，性能理論上會有提高

二、MySQL層面，對於日誌類型的系統，若是容許宕機的狀況下少許數據丟失，能夠將innodb_flush_log_at_trx_commit參數調整爲2，

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

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

三、系統層面，更換性能更佳的磁盤

 

 獲取更及時的文章信息，請關注個人微信公衆號