壓力測試過程中，如果因為資源使用瓶頸等問題引發(fā)最直接性能問題是業(yè)務(wù)交易響應(yīng)時間偏大，TPS逐漸降低等。而問題定位分析通常情況下，最優(yōu)先排查的是監(jiān)控服務(wù)器資源利用率，例如先用TOP 或者nmon等查看CPU、內(nèi)存使用情況，然后在排查IO問題，例如網(wǎng)絡(luò)IO、磁盤IO的問題。 如果是磁盤IO問題，一般問題是SQL語法問題、MYSQL參數(shù)配置問題、服務(wù)器自身硬件瓶頸導(dǎo)致IOPS吞吐率問題。

本文主要給大家介紹的是關(guān)于MySQL服務(wù)器 IO 100%的分析與優(yōu)化方案，下面話不多說了，來一起看看詳細的介紹吧

【問題】

有臺MySQL 5.6.21的數(shù)據(jù)庫實例以寫入為主，IO %util接近100%

寫入IOPS很高

【分析過程】

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

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

3、9號文件對應(yīng)的是redo log的第一個文件

為什么mysql進程會頻繁的刷新redo log文件，要結(jié)合redolog的刷盤策略來分析，關(guān)鍵是innodb_flush_log_at_trx_commit參數(shù)，

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

結(jié)合這個集群的寫入場景來看，大部分都是小事務(wù)的寫入，每次事務(wù)提交都會觸發(fā)刷盤動作，這種場景下通過增大innodb_log_buffer_size和innodb_log_file_size的優(yōu)化效果不明顯

【優(yōu)化方案】

1、應(yīng)用層面，對于寫壓力大的系統(tǒng)，可以將單條的insert語句優(yōu)化為小批量的insert語句，這樣事務(wù)commit的次數(shù)減少，redo log刷盤減少，性能理論上會有提升

2、MySQL層面，對于日志類型的系統(tǒng)，如果允許宕機的情況下少量數(shù)據(jù)丟失，可以將innodb_flush_log_at_trx_commit參數(shù)調(diào)整為2，

當設(shè)置為2時，則在事務(wù)提交時只做write操作，只保證寫到系統(tǒng)的page cache，因此實例crash不會丟失事務(wù)，但宕機則可能丟失事務(wù)

在這臺服務(wù)器上測試，將參數(shù)調(diào)整為2時，IO的請求從200M/S降到約10M/S壓力會減少10倍以上

3、系統(tǒng)層面，更換性能更佳的磁盤

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習或者工作具有一定的參考學(xué)習價值，如果有疑問大家可以留言交流，謝謝大家對本站的支持。

美國快速服務(wù)器

版權(quán)聲明：本站文章來源標注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非maisonbaluchon.cn所屬的服務(wù)器上建立鏡像，否則將依法追究法律責任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學(xué)習參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。