簡介：聽到IO夯總是讓人頭疼，那有沒有可以分析IO夯問題的利器？

編者按：sysAK（system analyse kit），是龍蜥社區(qū)（OpenAnolis）系統(tǒng)運(yùn)維 SIG 下面的一個(gè)開源項(xiàng)目，聚集阿里百萬服務(wù)器的多年運(yùn)維經(jīng)驗(yàn)，針對不同的運(yùn)維需求提供了一系列工具，形成統(tǒng)一的產(chǎn)品進(jìn)行服務(wù)。作者總結(jié)了實(shí)際工作中處理的 IO 夯問題的經(jīng)驗(yàn)，將它梳理成一套理論分析方法并形成 iosdiag 工具，集成到了sysAK 工具集里。本文將由作者帶大家一道領(lǐng)略一下 iosdiag 在 IO 夯領(lǐng)域叱咤風(fēng)云的魅力。本文整理自龍蜥大講堂第三期技術(shù)解讀，直播回顧可在龍蜥社區(qū)官網(wǎng)查看。

作者：李光水（君然）系統(tǒng)運(yùn)維SIG核心成員、 毛文安（品文）系統(tǒng)運(yùn)維SIG負(fù)責(zé)人。

一、引言

這是作者第二次備戰(zhàn)雙十一，懷著激動(dòng)的心情迎接雙十一的到來，不曾想迎來的是一枚深水炸彈：趕緊處理一下業(yè)務(wù)那邊出現(xiàn)的 Load 高問題。

“為什么 Load 高呢？”

“因?yàn)橛?500 多個(gè)進(jìn)程變成了 D 狀態(tài)?！?/p>

“那為什么會有這個(gè)多進(jìn)程 D 狀態(tài)呢？”

“因?yàn)槌霈F(xiàn)了 IO 夯問題...”

曾幾何時(shí)，聽到 IO 夯，作者會有點(diǎn)頭皮發(fā)麻，為啥呢？因?yàn)闆]有有效手段去定位這個(gè)問題，或者就算是有手段，也得經(jīng)歷山路十八彎，成不成還的看運(yùn)氣，若是幸運(yùn)，還能分析點(diǎn)啥出來，若是不幸運(yùn)，把機(jī)器整掛掉，得不償失。時(shí)至今日，遇到 IO 夯問題再也不虛了，因?yàn)樽髡攥F(xiàn)在手里有可以分析 IO 夯問題的利器——sysak iosdiag。

先來看看這個(gè)棧，500 多個(gè)進(jìn)程是因?yàn)樵趦?nèi)核下等待某個(gè)磁盤的塊設(shè)備互斥鎖而進(jìn)入 D 狀態(tài)，如圖 1-1 所示：

圖 1-1

互斥鎖正被執(zhí)行讀 IO 請求的內(nèi)核進(jìn)程 kworker 持有，如圖 1-2 所示，只有讀 IO 流程完成之后才能釋放鎖。但是因?yàn)?IO 夯住了，讀 IO 流程無法順利完成，所以就沒法正常釋放鎖了。所以接下來就需要找到是訪問哪塊磁盤出現(xiàn)了 IO 夯？IO 究竟夯在哪里？

圖1-2

之后作者使用 sysak iosdiag 工具找到了出現(xiàn) IO 夯問題的磁盤，同時(shí)也定位出來這個(gè) IO 是夯在了磁盤側(cè)，如圖 1-3 所示：

圖1-3

作者通過查詢 virtio 的后端磁盤的硬件隊(duì)列的 IO 信息，發(fā)現(xiàn) IO 實(shí)際已經(jīng)處理完了，進(jìn)一步查詢 vring 信息，發(fā)現(xiàn)后端沒有更新 used ring，最終將問題原因鎖定到了 virtio 后端。最后此問題的具體修復(fù)方法我們在此不再一一表述，總之，該工具可以方便的定界到問題出自前端驅(qū)動(dòng)還是后端設(shè)備側(cè)，節(jié)省了不少人力。

經(jīng)過此問題，作者也簡單做了下總結(jié)，聊一下 IO 夯的那些事。

二、史詩級的IO架構(gòu)

在聊 IO 夯之前，了解一個(gè) IO 會經(jīng)過哪些路徑還是很有必要的。網(wǎng)上有各式各樣的 IO 架構(gòu)圖，足以讓人看到眼花撩亂；作者從一個(gè) IO 的生命周期的角度畫了一幅圖，然后描述一個(gè) IO 在不同階段的那些事兒（下圖中去掉了部分軟件層次，如 dm、lvm 等），流程有點(diǎn)長，請耐心看完～

圖 2-1

假設(shè)我們以一次用戶態(tài)程序的寫 IO 為例，那么在調(diào)用 write 時(shí)候會傳入一個(gè)數(shù)據(jù) buf，這個(gè) buf 在內(nèi)核層面也是有對應(yīng)page的。在默認(rèn)情況下，IO 會以 buffer io 方式往下走；

假設(shè)以 buffer io 方式往下走，走到文件系統(tǒng)層，會將 1 中 buf 里面的數(shù)據(jù)拷貝到內(nèi)核 page cache 中，然后把這些 page 置臟，如果此時(shí)系統(tǒng)的臟頁水位還沒有達(dá)到系統(tǒng)所設(shè)置的閾值，這里就返回了，對用戶而言這次 IO 結(jié)束了；如果此時(shí)臟頁水位達(dá)到系統(tǒng)所設(shè)置的閾值，那么就會啟動(dòng)刷臟流程，這里根據(jù)臟頁水位具體達(dá)到的不同閾值，對用戶進(jìn)程會有不同的處理策略，如短暫休眠或不休眠，在此之后依舊會返回，用戶一次 IO 結(jié)束；

刷臟是通過 writeback 機(jī)制進(jìn)行，這一流程的觸發(fā)，可能是通過定期觸發(fā)，或者如 2 所說水位已經(jīng)超過系統(tǒng)所設(shè)定的閾值了，又或者是用戶執(zhí)行了同步命令或者調(diào)用了 sync/fsync 之類的 api 等等。writeback 機(jī)制將臟頁回寫包裝成一個(gè)個(gè) work，然后這些 work 由系統(tǒng)的 worker 進(jìn)程，也就是內(nèi)核的 kworker 進(jìn)程來執(zhí)行。刷臟的過程以一個(gè)個(gè) inode 為單位，然后將其中的臟頁進(jìn)一步包裝成 bio 結(jié)構(gòu)（bio 結(jié)構(gòu)中，會有一個(gè) bio_vec 來描述被包裝的臟頁 page，簡單理解就是會有一個(gè) page 指針指向這個(gè)臟頁），之后將 bio 提交到 block 層；當(dāng)然如果此次 IO 涉及到文件系統(tǒng)元數(shù)據(jù)的變更，中途內(nèi)核進(jìn)程 jbd 也會往 block 層提交 bio；

bio 進(jìn)入 block 層之后會經(jīng)歷一系列的限制性的處理，如這個(gè) bio 所包裝的數(shù)據(jù)長度是否過大，有或者是否已經(jīng)觸發(fā)到 IO 限流，因?yàn)檫@些機(jī)制有點(diǎn)小復(fù)雜，就不在圖上展示了。在此之后，會嘗試與已有的 IO 請求進(jìn)行合并，具體合并則根據(jù) bio 所描述磁盤上起始扇區(qū)和長度與 IO 請求中 bio 描述的磁盤地址是否連續(xù)來進(jìn)行合并。如能合并就不再往下，直接返回了；

如不能合并，則申請一個(gè)新的 IO 請求，在多隊(duì)列架構(gòu)中，根據(jù)磁盤的隊(duì)列個(gè)數(shù)和隊(duì)列深度，在磁盤初始化階段，在內(nèi)存上對每條硬件隊(duì)列已經(jīng)預(yù)先分配了一個(gè) request 集合，同時(shí)會有對應(yīng)的 bitmap 來表示每個(gè)請求是否已經(jīng)被申請。當(dāng)沒有請求可以被申請到時(shí)，說明此隊(duì)列上的 IO 請求已經(jīng)滿了，申請的進(jìn)程將進(jìn)入深度休眠等待隊(duì)列上的 IO 請求已經(jīng)成功刷到磁盤并釋放 IO 請求，才能申請到；

申請到之后，將 bio 包裝成 IO 請求——request，將 IO 請求添加到進(jìn)程的 plug 隊(duì)列中，當(dāng)積蓄到一定量的 IO 請求之后，一把“泄洪”到派發(fā)隊(duì)列上；（補(bǔ)充說明：plug隊(duì)列“蓄流”機(jī)制屬內(nèi)核行為，用戶無法控制，plug 隊(duì)列能積累的 IO 請求數(shù)也是有限制的；觸發(fā)“泄洪”，有可能是 plug 隊(duì)列滿了自己觸發(fā)的，也有可能是提交完一段數(shù)據(jù)之后，主動(dòng)調(diào)用的內(nèi)核接口觸發(fā)）；

request 進(jìn)入派發(fā)隊(duì)列之后，會被派發(fā)到驅(qū)動(dòng)層，上圖以 virtio blk 為例，request 會被封裝成一個(gè)個(gè) sg，這些 sg 里面有描述數(shù)據(jù) page 的物理地址、本次 IO 訪問的磁盤起始扇區(qū)、數(shù)據(jù)長度等信息。之后驅(qū)動(dòng)將 sg 推入到 vring 緩存中，vring緩存在主機(jī)上，是主機(jī)上 virtio blk 前端和后端磁盤共享的一塊可 dma 訪問的內(nèi)存。sg 推入 vring 之后，會 kick 磁盤提取 IO 并通過 dma 完成數(shù)據(jù)傳輸，IO 完成之后，磁盤給主機(jī)一個(gè)中斷，virtio blk 驅(qū)動(dòng)從 vring 中取出完成的 request，進(jìn)入 io cpmplete 路徑；

request 進(jìn)入 io complete 路徑之后，首先執(zhí)行在 bio 結(jié)構(gòu)體中設(shè)置的回調(diào)函數(shù)，這些回調(diào)函數(shù)一般在創(chuàng)建 bio 的的流程中指定，其一般負(fù)責(zé)喚醒等待進(jìn)程、釋放鎖資源的操作；之后會記錄 io stat 信息，這些信息也是系統(tǒng) iostat 工具的指標(biāo)來源；最后釋放掉 request，這個(gè)釋放并不是將 request 內(nèi)存清空，而是清除該 reqeust 對應(yīng)的在硬件隊(duì)列 request 集合上的 bitmap 位，以便于后來的 IO 可以再去申請使用；

至此，一個(gè) IO 的生命周期結(jié)束，而對于 direct io 的方式，整個(gè)過程會缺少數(shù)據(jù)buf復(fù)制到內(nèi)核 page cache、臟頁回寫這個(gè)步驟。上面提到的流程可能不是一個(gè)完成 IO 生命周期的全部，由于 IO 鏈路的復(fù)雜性，中間也省掉了部分流程，有興趣的讀者可以再去摸索摸索，或者加入我們系統(tǒng)運(yùn)維 sig 交流群，歡迎一起探討。

三、臭名昭著的IO夯

3.1 何為IO夯

IO 夯，可簡單理解為 IO 路徑在一定程度上堵住了，輕則經(jīng)過特定路徑的 IO 不可訪問，重則整條 IO 路徑堵住不可用，任你多少 IO 丟下來，我就是沒反應(yīng)。為什么 IO 路徑會堵住呢，無外乎是在等待資源。

等待資源一般涉及的是 IO 路徑上不可重入的臨界區(qū)，要求進(jìn)程持有資源進(jìn)入、釋放資源退出，又或者是事物處理型，允許接受有限個(gè)進(jìn)程的事物，但要等待這些進(jìn)程的事物全部被處理完之后，才能接收新的進(jìn)程事物，開始處理新一輪的流程。而當(dāng)處于臨界區(qū)內(nèi)的進(jìn)程，由于內(nèi)核 bug 或存儲介質(zhì)原因，導(dǎo)致無法順利完成 IO 后正常退出，最終造成臨界區(qū)外的進(jìn)程因?yàn)槟貌坏劫Y源而處于阻塞狀態(tài)，導(dǎo)致無 IO 可用。由此可見，只要臨界區(qū)內(nèi)的進(jìn)程不退出這種尷尬的狀態(tài)，整條 IO 路徑就不可用。

圖 3-1

內(nèi)核下有條 io complete 的關(guān)鍵路徑，這條路徑屬于可重入路徑，其主要職責(zé)為對 IO 結(jié)束后的收尾工作，一般地，會先執(zhí)行一個(gè) IO 回調(diào)流程，而后更新一些 IO 的stat信息，最后結(jié)束生命周期。內(nèi)核中也有一些特殊類的 IO，在 IO 子系統(tǒng)中的處理方式與一般的 IO 有所差異，如 flush/fua io，而作者曾經(jīng)碰到過一起 flush/fua io 夯的問題。flush/fua io 在使用日志型的文件系統(tǒng)場景下可能會比較常見，如 ext4 文件系統(tǒng)，為了保證文件系統(tǒng)元數(shù)據(jù)能夠真正的持久化存儲到磁盤的日志區(qū)域，jbd 線程在提交 commit record 的時(shí)候會發(fā)起這種 IO，而flush/fua io的處理流程也是比較繁瑣的：

圖 3-2

如上圖所示，IO 子系統(tǒng)在處理這個(gè) IO 時(shí)，會先發(fā)起一個(gè) flush io 到磁盤（在內(nèi)核中喚作pre-flush），等這個(gè) IO 結(jié)束之后，再發(fā)起真正的數(shù)據(jù) IO，當(dāng)磁盤執(zhí)行完數(shù)據(jù) IO 之后，再此發(fā)起一個(gè)flush io（在內(nèi)核中也喚作 post-flush），終于 flush io 結(jié)束之后，數(shù)據(jù) IO 進(jìn)入complete 路徑。在這個(gè)數(shù)據(jù) IO 里面，一般會存在比較關(guān)鍵的 IO 回調(diào)，其涉及到釋放 buffer head 的 lock bit 或者 page cache 的 lock bit，而且往往等待這個(gè) lock bit 的是 jbd 線程本身；作者曾經(jīng)就遇到 pre-flush io 因?yàn)?race 問題被直接釋放掉了，導(dǎo)致后續(xù)的 IO 流程沒有走到，data io 沒有得到處理，buffer lock 得不到釋放，造成 jbd 夯住，最終引起這個(gè)分區(qū)的 IO 都得不到響應(yīng)。

經(jīng)過本小節(jié)的介紹，結(jié)合章節(jié) 2 的 IO 結(jié)構(gòu)圖（圖 2-1），可以發(fā)現(xiàn) IO 夯是可以發(fā)生 IO 路徑上的任何地方。

3.2 IO夯的危害

從 3.1 可知，IO 夯會造成有 IO 需求的進(jìn)程無 IO 可用；從業(yè)務(wù)穩(wěn)定性角度來看，對于那些有 IO 訪問需求的業(yè)務(wù)進(jìn)程，IO 夯可能會引起進(jìn)程長期阻塞，且在 IO 路徑恢復(fù)之前，都無法對外提供服務(wù)。從系統(tǒng)穩(wěn)定性角度來看，IO 夯可能會引起大量的進(jìn)程進(jìn)入 D 狀態(tài)，導(dǎo)致系統(tǒng)高負(fù)載，甚至系統(tǒng)夯住，shell 命令無法執(zhí)行，機(jī)器無法登陸，最終不得不重啟系統(tǒng)去解決。

3.3 IO夯問題分析方法現(xiàn)狀

當(dāng)遇到 IO 夯問題時(shí)，我們通常會分析 dmesg 中 hungtask 調(diào)用棧、或者是 iosta 信息、sysfs/debugfs 中的統(tǒng)計(jì)信息，再結(jié)合以往經(jīng)驗(yàn)去推測問題可能出在哪。當(dāng)我們碰到如下圖 3-3 所示的 iostat 信息時(shí)，根據(jù)經(jīng)驗(yàn)，會懷疑是磁盤側(cè)有 IO 沒回，因此懷疑io夯在磁盤上，讓存儲的同學(xué)去排查磁盤側(cè)。但這種經(jīng)驗(yàn)卻不一定靠譜，如果是在磁盤返回到 io complete 之間有內(nèi)核 bug，iostat 也會出現(xiàn)下圖中的信息。

圖 3-3

那如何分析 IO 夯問題是最有效的呢？答案肯定是要找出來夯住的 IO 請求，然后根據(jù)請求里面的信息去分析當(dāng)前這個(gè)請求是處于什么狀態(tài)、已經(jīng)走到哪個(gè)路徑了。但遺憾的是，目前沒有實(shí)現(xiàn)這個(gè)功能的通用工具，唯一能快速實(shí)現(xiàn)這一需求的，就只有對問題現(xiàn)場做 crash 分析了，找到夯住的 IO 請求，根據(jù) IO 請求中的信息，再結(jié)合代碼流程，一步步深入最終找到問題原因，但前提是業(yè)務(wù)可以容忍這么操作。

3.4 利器簡介——sysak iosdiag

sysAK iosdiag，是 sysAK 工具平臺中的 IO 診斷工具，已具備 IO 時(shí)延探測、IO 夯診斷兩大功能，其中 IO 夯診斷可用于檢測當(dāng)前系統(tǒng)中 IO 夯事件并確定問題邊界。工具的大體架構(gòu)圖 3-4 所示：

圖 3-4

首先通過 sysAK 的 iosdiag 功能去使能 IO 夯診斷，這里診斷到 IO 夯之后，會對 IO 進(jìn)行數(shù)據(jù)分析，然后形成診斷結(jié)論，診斷結(jié)論是以 json 的數(shù)據(jù)格式保存在一個(gè)日志文件里面，同時(shí)也支持將數(shù)據(jù)上傳到指定的地方，目前支持 oss 的上傳方式，不上傳的話，數(shù)據(jù)也會存在機(jī)器本地，供調(diào)用者去查看。

圖 3-5

工具的性能開銷情況：單核 cpu 低于 1%、內(nèi)存消耗低于 10MB、消耗少許磁盤空間保存診斷結(jié)果。

工具支持的內(nèi)核版本種類：3.10/4.9/4.19多種版本。

iosdiag 診斷結(jié)果輸出，力求信息準(zhǔn)確、結(jié)果直觀，期望即便不具備內(nèi)核IO子系統(tǒng)知識的同學(xué)也能快速上手。工具會輸出一些結(jié)論性的信息，如什么時(shí)間點(diǎn)，檢測到了 IO 事件，這是一個(gè)什么樣的 IO，從哪個(gè) cpu 發(fā)出來的，從哪個(gè)磁盤的哪個(gè)位置訪問多大的數(shù)據(jù)量，然后這個(gè) IO 夯在哪個(gè)路徑上，夯住了多久。

圖 3-6

四、TODO

工具目前只能覆蓋到進(jìn)入內(nèi)核 block 層的 IO，在 block 之上的覆蓋不到，因此作者目前也在研究如何擴(kuò)大工具的覆蓋面；其次，工具在結(jié)果輸出上還不夠直觀，使用者還無法簡單明了地從輸出信息上看到問題，針對這一點(diǎn)，作者也一直在優(yōu)化。

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

總結(jié)

以上是生活随笔為你收集整理的直播回顾：如何对付臭名昭著的 IO 夯？诊断利器来了 | 龙蜥技术的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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