前言
壓力測試過程中，如果因爲資源使用瓶頸等問題引發最直接性能問題是業務交易響應時間偏大，TPS逐漸降低等。而問題定位分析通常情況下，最優先排查的是監控服務器資源利用率，例如先用TOP 或者nmon等查看CPU、內存使用情況，然後在排查IO問題，例如網絡IO、磁盤IO的問題。 如果是磁盤IO問題，一般問題是SQL語法問題、MYSQL參數配置問題、服務器自身硬件瓶頸導致IOPS吞吐率問題。
本文主要給大家介紹的是關於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、系統層面，更換性能更佳的磁盤
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。