在沒(méi)有解決bug之前，你永遠(yuǎn)不知道bug到底是怎么產(chǎn)生的。

問(wèn)題緣起: 當(dāng)我習(xí)慣性地用top查看任務(wù)運(yùn)行狀態(tài)時(shí)，發(fā)現(xiàn)我運(yùn)行的100個(gè)任務(wù)，只有3個(gè)在運(yùn)行，其他都在摸魚(yú)狀態(tài)。同時(shí)發(fā)現(xiàn)我的任務(wù)進(jìn)程都是"D"狀態(tài)(未截圖)，而不是R(運(yùn)行)狀態(tài)。

top狀態(tài)

這個(gè)時(shí)候，我直覺(jué)上感覺(jué)這是硬盤(pán)讀寫(xiě)除了問(wèn)題，于是我開(kāi)始檢索查找相關(guān)工具去驗(yàn)證我的猜想

先用的是iostat -x 2 10，如果%util 接近100%說(shuō)明產(chǎn)生的I/O請(qǐng)求太多，I/O系統(tǒng)滿負(fù)荷，%idle小于70%，IO壓力就很大。

iostat 結(jié)果

從上圖明顯發(fā)現(xiàn)我的IO壓力過(guò)大。當(dāng)然作為科研人員，我們都知道我們需要多個(gè)證據(jù)才能證實(shí)自己的猜想，于是進(jìn)一步用iotop, 發(fā)現(xiàn)有許多進(jìn)程的IO居然是99%.

iotop

既然確定服務(wù)器性能下降的原因是IO。那么下一步就是找到導(dǎo)致磁盤(pán)壓力過(guò)大的真兇。用dstat --top-bio-adv找到那個(gè)進(jìn)程占用IO最多， 此處發(fā)現(xiàn)是jdb2/sda1-8 的寫(xiě)出數(shù)據(jù)超多

dstat --top-bio-adv

利用關(guān)鍵字"jdb2/sda1-8"經(jīng)過(guò)搜索，發(fā)現(xiàn)很多人都遇到這種情況，

• 有些認(rèn)為是RAID磁盤(pán)矩陣導(dǎo)致的問(wèn)題
• 有人認(rèn)為是MySQL的問(wèn)題。

剛好，我的服務(wù)器是RAID，又剛好我今天改動(dòng)了MySQL。但是直覺(jué)告訴我，應(yīng)該不是這兩個(gè)問(wèn)題，因?yàn)槲译m然改了MySQL的配置文件，但是我基本不用MySQL, 所以排除這個(gè)可能。

但是，目前我已經(jīng)順利確認(rèn)就是"jdb2/sdax-y"的問(wèn)題(x表示是分區(qū))，于是我就主要檢索了jdb2

jbd2的全稱是journaling block driver 。這個(gè)進(jìn)程實(shí)現(xiàn)的是文件系統(tǒng)的日志功能，磁盤(pán)使用日志功能來(lái)保證數(shù)據(jù)的完整性。這個(gè)需要評(píng)估一下安全和性能哪個(gè)更重要，對(duì)于一個(gè)應(yīng)用服務(wù)器來(lái)說(shuō)，并不保存重要的用戶數(shù)據(jù)，只是實(shí)現(xiàn)業(yè)務(wù)邏輯。如果是數(shù)據(jù)庫(kù)的話，就需要考慮啟動(dòng)磁盤(pán)寫(xiě)入的完整性檢查。但是現(xiàn)在大部分系統(tǒng)在業(yè)務(wù)和架構(gòu)層面已經(jīng)考慮了業(yè)務(wù)完整性。所以為性能計(jì)，這里并不是非常有必須啟動(dòng)日志功能。

網(wǎng)絡(luò)上的人提供了如下三種解決方案:

• 升級(jí)內(nèi)核
• 更改commit的次數(shù)， "mount -o remount,commit=60 /dev/sda1"
• 關(guān)閉文件系統(tǒng)日志功能: 操作類(lèi)似于dumpe2fs 獲取文件系統(tǒng)屬性信息, tune2fs 調(diào)整文件系統(tǒng)屬性, 之后e2fsck 檢查文件系統(tǒng)(幾乎大部分都不推薦這樣做)

當(dāng)然這些方案，我一個(gè)都沒(méi)有采納，因?yàn)槲彝蝗幌氲浇裉旆?wù)器上似乎運(yùn)行了許多IO操作很頻繁的程序，jdb2的特點(diǎn)就是犧牲了性能保證了數(shù)據(jù)完整性，也就是說(shuō)是我運(yùn)行的程序太多讓jdb2忙不過(guò)來(lái)了。

因此我的最終解決方案就是，用kill把所有當(dāng)前運(yùn)行的高IO程序都干掉。最后解決了問(wèn)題。

問(wèn)題解決