一次服務器IO佔用率高的定位分析

背景：請假在外中，聽平臺組同事反饋了一個問題，在往生產數據庫中導入部分數據時會形成客戶端的訪問超時，初步定位是由於服務器磁盤佔用IO太高，導數據時IO會飆升到100%，所以引發了很多數據庫的慢查詢操做致使客戶端響應超時，無奈只好暫時中止了導入數據的腳本，同時也延誤了針對這部分數據的生產測試工做。因而我次日回到公司就投入了對這個問題的跟蹤定位工做。

---

環境描述：

• 操做系統

  
  

• 文件系統

  
  

• 數據庫

  
  

首先咱們數據庫某最大表的數據也不過300w多條，對於MySQL來講仍是可以正常處理的。並且客戶端併發量也不過1K多，數據庫的TPS也未過百，我前後使用了top，iostat監測到的IO利用率確實都已經達到極限了。最後使用iotop這個工具發現了一個吃IO的罪犯jbd2

Overview
The Journaling Block Device (JBD) provides a filesystem-independent interface for filesystem journaling. ext3, ext4 and OCFS2 are known to use JBD. OCFS2 starting from linux 2.6.28 and ext4 use a fork of JBD called JBD2.

能夠知曉它的主要功能是向文件系統寫日誌。那麼確定是因爲對文件系統的操做太頻繁致使的IO壓力過大，問題這是個系統進程，是系統問題仍是？

目前我這臺服務器上只有一個應用須要大量操做IO，那就是MySQL數據庫，會不會由他致使的？懷着這個疑問我用google將mysql和jbd2聯合做爲關鍵字進行搜索，獲得了這麼一個線索sync_binlog，innodb_flush_log_at_trx_commit這兩個mysql的配置項。頓時我彷彿想起了什麼，因而翻到《高性能MySQL》這本書的第10章——複製的章節（從上面的環境描述中能夠看到我使用了MySQL的主主複製）找到了對sync_binlog的說明

那麼innodb_flush_log_at_trx_commit呢？

• 若是innodb_flush_log_at_trx_commit設置爲0，log buffer將每秒一次地寫入log file中，而且log file的flush(刷到磁盤)操做同時進行.該模式下，在事務提交的時候，不會主動觸發寫入磁盤的操做。

• 若是innodb_flush_log_at_trx_commit設置爲1，每次事務提交時MySQL都會把log buffer的數據寫入log file，而且flush(刷到磁盤)中去.

• 若是innodb_flush_log_at_trx_commit設置爲2，每次事務提交時MySQL都會把log buffer的數據寫入log file.可是flush(刷到磁盤)操做並不會同時進行。該模式下,MySQL會每秒執行一次 flush(刷到磁盤)操做。

因爲咱們的業務數據的特色，對數據可靠性並不如金融、訂單系統那麼高因而在權衡下就把sync_binlog設置爲每500次刷新一次磁盤，而將innodb_flush_log_at_trx_commit設置爲2，再用iotop等工具查看系統IO狀況，大大降了下來。好吧，這個借刀殺IO的罪犯終於找到並被處理了。

後記：在此次處理問題的過程當中有兩個小插曲。

1. 某領導找來幾我的對此問題進行會診，有猜想服務器資源不夠的，有猜想腳本問題的，有猜想數據庫自己效率底下的…我我的很是很是反感在沒有通過性能監控和數據的分析而憑空猜想問題的作法。我但願給全部靠憑空想象定位問題的人提個醒，請不要隨意對本身不瞭解的問題定性，由於別人不會把你看作高手，只會對你視而不見。

2. 在找出jbd2的問題以後，看到一些論壇解決方案說是因爲linux內核的bug能夠選擇升級系統內核或者修改內核配置項來解決，也許是對的，可是即便能解決這個問題對我來講成本也很大。我但願你們遇到問題時在利用網絡資源的同時結合本身的狀況進行進一步分析再選擇採用什麼解決方案，適合本身的纔是最好的。

參考資料：
http://unix.stackexchange.com/questions/86875/determining-specific-file-responsible-for-high-i-o
http://serverfault.com/questions/363355/io-wait-causing-so-much-slowdown-ext4-jdb2-at-99-io-during-mysql-commit
http://blog.itpub.net/22664653/viewspace-1063134/