前言
壓力測試過程中，如果因為資源使用瓶頸等問題引發最直接效能問題是業務交易響應時間偏大，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(刷到磁碟)中去。
結合這個集群的寫入場景feszwjfmiw來看，程式設計客棧大部分都是小事務的寫入，每次事務提交都會觸發刷盤動作，這種場景下通過增大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、系統層面，更換效能更佳的磁碟
總結本文標題: mysql伺服器 io 100%的分析與優化方案
本文位址: /shujuku/mysql/242510.html
MySQL伺服器 IO 100 的案例分析
問題 有台mysql 5.6.21的資料庫例項以寫入為主，io util接近100 寫入iops很高 分析過程 1 通過iotop工具可以看到當前io消耗最高的mysql執行緒 2 檢視執行緒49342的堆疊，可以看到正在進行redo log的重新整理，對應的是9號檔案 3 9號檔案對應的是redo...
MySQL伺服器 IO 100 的案例分析
原文 mysql伺服器 io 100 的案例分析 問題 有台mysql 5.6.21的資料庫例項以寫入為主，io util接近100 寫入iops很高 分析過程 1 通過iotop工具可以看到當前io消耗最高的mysql執行緒 2 檢視執行緒49342的堆疊，可以看到正在進行redo log的重新整...
MySQL伺服器CPU跑滿100 的情況分析
我們的原則是,重啟能解決的,絕對不開client cpu100 通常情況下就是有慢sql造成的，這裡的慢sql包括全表掃瞄，掃瞄資料量過大，記憶體排序，磁碟排序，鎖爭用等待等.一般表現現象sql執行狀態為 sending data，copying to tmp table，copying to tm...