? ? 前幾天碰到j(luò)bd2進(jìn)程占用大量的磁盤io，用iotop查看到的情況大致如下：

系統(tǒng)版本：CentOS6.5-64bit

????經(jīng)查為ext4文件系統(tǒng)的一個bug:

????先給出解決方案，處理此問題的優(yōu)先級為：

1、yum update kernel 用yum升級系統(tǒng)內(nèi)核，重啟之后查看是否有效；

2、緩解方法：修改commit值，降低文件系統(tǒng)提交次數(shù)或者禁用barrier特性；

建議文件系統(tǒng)參數(shù)為：defaults,noatime,nodiratime,barrier=0,data=writeback,commit=60

（可以通過修改fstab表或者remount重新掛載）

3、慎用方法：關(guān)閉文件系統(tǒng)日志功能 ? ? tune2fs -O "^has_journal" 例如：?tune2fs -O "^has_journal"?/dev/mapper/VolGroup-lv_home

-----------------------------------------------------------------------

????通過查資料，整理相關(guān)信息，解釋如下；

1、jbd的全拼是journaling block driver 文件系統(tǒng)的日志功能，jbd2是ext4文件系統(tǒng)版本；可以肯定的是對文件系統(tǒng)的操作太頻繁，導(dǎo)致IO壓力過大。

常用的文件系統(tǒng)使用日志功能來保證文件系統(tǒng)的完整性，在寫入新的數(shù)據(jù)到磁盤之前，會先將元數(shù)據(jù)寫入日志；這樣做可以保證在寫入真實(shí)數(shù)據(jù)前后，一旦發(fā)生錯誤，

日志功能將很容易回滾到之前的狀態(tài)，確保不會發(fā)生文件系統(tǒng)崩潰的情況；

2、而現(xiàn)在的磁盤上一般都配有內(nèi)部緩存，以便重新調(diào)整批量數(shù)據(jù)的寫入順序，優(yōu)化寫入性能，因此文件系統(tǒng)必須在日志數(shù)據(jù)寫入磁盤之后才能寫commit（commit=xx 每xx秒同步所有的數(shù)據(jù)和元數(shù)據(jù)。默認(rèn)是每5秒）記錄；若commit記錄寫入在先，而日志有可能損壞，就會影響數(shù)據(jù)完整性；EXT4文件系統(tǒng)默認(rèn)啟用barrier功能，只有當(dāng)barrier之前的數(shù)據(jù)全部寫入磁盤，才能寫barrier之后的數(shù)據(jù)；barrier的存在保證了數(shù)據(jù)完整性；

3、使用barrier特性的不利之處在于，需要付出降低性能的代價；可以通過掛載項(xiàng) mount -o barrier=0來禁用此特性；

? 可通過查看/proc/mounts里的barrier值 為1代表啟用

4、文件的寫和請求會導(dǎo)致其中一個int型的值不斷增大，最后超出了自身范圍---變成負(fù)值，就會觸發(fā)該bug;

?具體原理參考下鏈接：

http://blog.donghao.org/2013/03/20/%E4%BF%AE%E5%A4%8Dext4%E6%97%A5%E5%BF%97%EF%BC%88jbd2%EF%BC%89bug/

5、所以我們可以通過降低文件系統(tǒng)的提交次數(shù)來緩解IO壓力（相關(guān)參數(shù)commit）；或者禁用barrier特性（相關(guān)參數(shù)barrier=0 ）;

?而考慮到此bug網(wǎng)上已經(jīng)有人提出了，貌似當(dāng)時還有人提供了臨時修復(fù)補(bǔ)丁，這么長時間過去之后，官方kernel里也應(yīng)該做了相應(yīng)的更新；所以當(dāng)大家碰到這個問題時，首先的建議是

升級下kernel（升級之前建議做好數(shù)據(jù)備份），重啟之后查看是否生效！

? ? ? 本文轉(zhuǎn)自Jx戰(zhàn)壕 ?51CTO博客，原文鏈接：http://blog.51cto.com/xujpxm/1674378，如需轉(zhuǎn)載請自行聯(lián)系原作者

總結(jié)

以上是生活随笔為你收集整理的JDB2导致磁盘io使用率高的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。