MySQL服務器 IO 100%的分析與優化方案

前言

壓力測試過程當中，若是由於資源使用瓶頸等問題引起最直接性能問題是業務交易響應時間偏大，TPS逐漸下降等。而問題定位分析一般狀況下，最優先排查的是監控服務器資源利用率，例如先用TOP 或者nmon等查看CPU、內存使用狀況，而後在排查IO問題，例如網絡IO、磁盤IO的問題。 若是是磁盤IO問題，通常問題是SQL語法問題、MYSQL參數配置問題、服務器自身硬件瓶頸致使IOPS吞吐率問題。

本文主要給你們介紹的是關於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倍以上

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

總結

以上就是這篇文章的所有內容了，但願本文的內容對你們的學習或者工做具備必定的參考學習價值，若是有疑問你們能夠留言交流，謝謝你們對腳本之家的支持。

您可能感興趣的文章:

• Mysql IO 內存方面的優化

文章同步發佈： https://www.geek-share.com/detail/2751092551.html