《如何提高Linux下塊設(shè)備IO的整體性能？》要點(diǎn)：
本文介紹了如何提高Linux下塊設(shè)備IO的整體性能？，希望對您有用。如果有疑問，可以聯(lián)系我們。

編輯手記：本文主要講解Linux IO調(diào)度層的三種模式：cfp、deadline和noop,并給出各自的優(yōu)化和適用場景建議.

作者簡介：

鄒立巍

Linux系統(tǒng)技術(shù)專家.目前在騰訊SNG社交網(wǎng)絡(luò)運(yùn)營部 計(jì)算資源平臺組,負(fù)責(zé)內(nèi)部私有云平臺的建設(shè)和架構(gòu)規(guī)劃設(shè)計(jì).

曾任新浪動態(tài)應(yīng)用平臺系統(tǒng)架構(gòu)師,負(fù)責(zé)微博、新浪博客等重點(diǎn)業(yè)務(wù)的內(nèi)部私有云平臺架構(gòu)設(shè)計(jì)和運(yùn)維管理工作.

IO調(diào)度發(fā)生在Linux內(nèi)核的IO調(diào)度層.這個層次是針對Linux的整體IO層次體系來說的.從read()或者write()系統(tǒng)調(diào)用的角度來說,Linux整體IO體系可以分為七層,它們分別是：

1. VFS層：虛擬文件系統(tǒng)層.由于內(nèi)核要跟多種文件系統(tǒng)打交道,而每一種文件系統(tǒng)所實(shí)現(xiàn)的數(shù)據(jù)結(jié)構(gòu)和相關(guān)方法都可能不盡相同,所以,內(nèi)核抽象了這一層,專門用來適配各種文件系統(tǒng),并對外提供統(tǒng)一操作接口.
2. 文件系統(tǒng)層：不同的文件系統(tǒng)實(shí)現(xiàn)自己的操作過程,提供自己特有的特征,具體不多說了,大家愿意的話自己去看代碼即可.
3. 頁緩存層：負(fù)責(zé)真對page的緩存.
4. 通用塊層：由于絕大多數(shù)情況的io操作是跟塊設(shè)備打交道,所以Linux在此提供了一個類似vfs層的塊設(shè)備操作抽象層.下層對接各種不同屬性的塊設(shè)備,對上提供統(tǒng)一的Block IO請求標(biāo)準(zhǔn).
5. IO調(diào)度層：因?yàn)榻^大多數(shù)的塊設(shè)備都是類似磁盤這樣的設(shè)備,所以有必要根據(jù)這類設(shè)備的特點(diǎn)以及應(yīng)用的不同特點(diǎn)來設(shè)置一些不同的調(diào)度算法和隊(duì)列.以便在不同的應(yīng)用環(huán)境下有針對性的提高磁盤的讀寫效率,這里就是大名鼎鼎的Linux電梯所起作用的地方.針對機(jī)械硬盤的各種調(diào)度方法就是在這實(shí)現(xiàn)的.
6. 塊設(shè)備驅(qū)動層：驅(qū)動層對外提供相對比較高級的設(shè)備操作接口,往往是C語言的,而下層對接設(shè)備本身的操作方法和規(guī)范.
7. 塊設(shè)備層：這層就是具體的物理設(shè)備了,定義了各種真對設(shè)備操作方法和規(guī)范.

有一個已經(jīng)整理好的[Linux IO結(jié)構(gòu)圖],非常經(jīng)典,一圖勝千言：

我們今天要研究的內(nèi)容主要在IO調(diào)度這一層.

它要解決的核心問題是,如何提高塊設(shè)備IO的整體性能?這一層也主要是針對機(jī)械硬盤結(jié)構(gòu)而設(shè)計(jì)的.

眾所周知,機(jī)械硬盤的存儲介質(zhì)是磁盤,磁頭在盤片上移動進(jìn)行磁道尋址,行為類似播放一張唱片.

這種結(jié)構(gòu)的特點(diǎn)是,順序訪問時吞吐量較高,但是如果一旦對盤片有隨機(jī)訪問,那么大量的時間都會浪費(fèi)在磁頭的移動上,這時候就會導(dǎo)致每次IO的響應(yīng)時間變長,極大的降低IO的響應(yīng)速度.

磁頭在盤片上尋道的操作,類似電梯調(diào)度,實(shí)際上在最開始的時期,Linux把這個算法命名為Linux電梯算法,即：

如果在尋道的過程中,能把順序路過的相關(guān)磁道的數(shù)據(jù)請求都“順便”處理掉,那么就可以在比較小影響響應(yīng)速度的前提下,提高整體IO的吞吐量.

這就是我們?yōu)槭裁匆O(shè)計(jì)IO調(diào)度算法的原因.

目前在內(nèi)核中默認(rèn)開啟了三種算法/模式：noop,cfq和deadline.嚴(yán)格算應(yīng)該是兩種：

因?yàn)榈谝环N叫做noop,就是空操作調(diào)度算法,也就是沒有任何調(diào)度操作,并不對io請求進(jìn)行排序,僅僅做適當(dāng)?shù)膇o合并的一個fifo隊(duì)列.

目前內(nèi)核中默認(rèn)的調(diào)度算法應(yīng)該是cfq,叫做完全公平隊(duì)列調(diào)度.這個調(diào)度算法人如其名,它試圖給所有進(jìn)程提供一個完全公平的IO操作環(huán)境.

請大家一定記住這個詞語,cfq,完全公平隊(duì)列調(diào)度,不然下文就沒法看了.

cfq為每個進(jìn)程創(chuàng)建一個同步IO調(diào)度隊(duì)列,并默認(rèn)以時間片和請求數(shù)限定的方式分配IO資源,以此保證每個進(jìn)程的IO資源占用是公平的,cfq還實(shí)現(xiàn)了針對進(jìn)程級別的優(yōu)先級調(diào)度,這個我們后面會詳細(xì)解釋.

查看和修改IO調(diào)度算法的方法是：

cfq是通用服務(wù)器比較好的IO調(diào)度算法選擇,對桌面用戶也是比較好的選擇.

但是對于很多IO壓力較大的場景就并不是很適應(yīng),尤其是IO壓力集中在某些進(jìn)程上的場景.

因?yàn)檫@種場景我們需要更多的滿足某個或者某幾個進(jìn)程的IO響應(yīng)速度,而不是讓所有的進(jìn)程公平的使用IO,比如數(shù)據(jù)庫應(yīng)用.

deadline調(diào)度(最終期限調(diào)度)就是更適合上述場景的解決方案.deadline實(shí)現(xiàn)了四個隊(duì)列：

• 其中兩個分別處理正常read和write,按扇區(qū)號排序,進(jìn)行正常io的合并處理以提高吞吐量.因?yàn)镮O請求可能會集中在某些磁盤位置,這樣會導(dǎo)致新來的請求一直被合并,可能會有其他磁盤位置的io請求被餓死.
• 另外兩個處理超時read和write的隊(duì)列,按請求創(chuàng)建時間排序,如果有超時的請求出現(xiàn),就放進(jìn)這兩個隊(duì)列,調(diào)度算法保證超時(達(dá)到最終期限時間)的隊(duì)列中的請求會優(yōu)先被處理,防止請求被餓死.

不久前,內(nèi)核還是默認(rèn)標(biāo)配四種算法,還有一種叫做as的算法(Anticipatory scheduler),預(yù)測調(diào)度算法.一個高大上的名字,搞得我一度認(rèn)為Linux內(nèi)核都會算命了.

結(jié)果發(fā)現(xiàn),無非是在基于deadline算法做io調(diào)度的之前等一小會時間,如果這段時間內(nèi)有可以合并的io請求到來,就可以合并處理,提高deadline調(diào)度的在順序讀寫情況下的數(shù)據(jù)吞吐量.

其實(shí)這根本不是啥預(yù)測,我覺得不如叫撞大運(yùn)調(diào)度算法,當(dāng)然這種策略在某些特定場景差效果不錯.

但是在大多數(shù)場景下,這個調(diào)度不僅沒有提高吞吐量,還降低了響應(yīng)速度,所以內(nèi)核干脆把它從默認(rèn)配置里刪除了.畢竟Linux的宗旨是實(shí)用,而我們也就不再這個調(diào)度算法上多費(fèi)口舌了.

1、cfq：完全公平隊(duì)列調(diào)度

cfq是內(nèi)核默認(rèn)選擇的IO調(diào)度隊(duì)列,它在桌面應(yīng)用場景以及大多數(shù)常見應(yīng)用場景下都是很好的選擇.

如何實(shí)現(xiàn)一個所謂的完全公平隊(duì)列(Completely Fair Queueing)?

首先我們要理解所謂的公平是對誰的公平?從操作系統(tǒng)的角度來說,產(chǎn)生操作行為的主體都是進(jìn)程,所以這里的公平是針對每個進(jìn)程而言的,我們要試圖讓進(jìn)程可以公平的占用IO資源.

那么如何讓進(jìn)程公平的占用IO資源?我們需要先理解什么是IO資源.當(dāng)我們衡量一個IO資源的時候,一般喜歡用的是兩個單位,一個是數(shù)據(jù)讀寫的帶寬,另一個是數(shù)據(jù)讀寫的IOPS.

帶寬就是以時間為單位的讀寫數(shù)據(jù)量,比如,100Mbyte/s.而IOPS是以時間為單位的讀寫次數(shù).在不同的讀寫情境下,這兩個單位的表現(xiàn)可能不一樣,但是可以確定的是,兩個單位的任何一個達(dá)到了性能上限,都會成為IO的瓶頸.

從機(jī)械硬盤的結(jié)構(gòu)考慮,如果讀寫是順序讀寫,那么IO的表現(xiàn)是可以通過比較少的IOPS達(dá)到較大的帶寬,因?yàn)榭梢院喜⒑芏郔O,也可以通過預(yù)讀等方式加速數(shù)據(jù)讀取效率.

當(dāng)IO的表現(xiàn)是偏向于隨機(jī)讀寫的時候,那么IOPS就會變得更大,IO的請求的合并可能性下降,當(dāng)每次io請求數(shù)據(jù)越少的時候,帶寬表現(xiàn)就會越低.

從這里我們可以理解,針對進(jìn)程的IO資源的主要表現(xiàn)形式有兩個：進(jìn)程在單位時間內(nèi)提交的IO請求個數(shù)和進(jìn)程占用IO的帶寬.

其實(shí)無論哪個,都是跟進(jìn)程分配的IO處理時間長度緊密相關(guān)的.

有時業(yè)務(wù)可以在較少IOPS的情況下占用較大帶寬,另外一些則可能在較大IOPS的情況下占用較少帶寬,所以對進(jìn)程占用IO的時間進(jìn)行調(diào)度才是相對最公平的.

即,我不管你是IOPS高還是帶寬占用高,到了時間咱就換下一個進(jìn)程處理,你愛咋樣咋樣.

所以,cfq就是試圖給所有進(jìn)程分配等同的塊設(shè)備使用的時間片,進(jìn)程在時間片內(nèi),可以將產(chǎn)生的IO請求提交給塊設(shè)備進(jìn)行處理,時間片結(jié)束,進(jìn)程的請求將排進(jìn)它自己的隊(duì)列,等待下次調(diào)度的時候進(jìn)行處理.這就是cfq的基本原理.

當(dāng)然,現(xiàn)實(shí)生活中不可能有真正的“公平”,常見的應(yīng)用場景下,我們很肯能需要人為的對進(jìn)程的IO占用進(jìn)行人為指定優(yōu)先級,這就像對進(jìn)程的CPU占用設(shè)置優(yōu)先級的概念一樣.

所以,除了針對時間片進(jìn)行公平隊(duì)列調(diào)度外,cfq還提供了優(yōu)先級支持.每個進(jìn)程都可以設(shè)置一個IO優(yōu)先級,cfq會根據(jù)這個優(yōu)先級的設(shè)置情況作為調(diào)度時的重要參考因素.

優(yōu)先級首先分成三大類：RT、BE、IDLE,它們分別是實(shí)時(Real Time)、最佳效果(Best Try)和閑置(Idle)三個類別,對每個類別的IO,cfq都使用不同的策略進(jìn)行處理.另外,RT和BE類別中,分別又再劃分了8個子優(yōu)先級實(shí)現(xiàn)更細(xì)節(jié)的QOS需求,而IDLE只有一個子優(yōu)先級.

另外,我們都知道內(nèi)核默認(rèn)對存儲的讀寫都是經(jīng)過緩存(buffer/cache)的,在這種情況下,cfq是無法區(qū)分當(dāng)前處理的請求是來自哪一個進(jìn)程的.

只有在進(jìn)程使用同步方式(sync read或者sync wirte)或者直接IO(Direct IO)方式進(jìn)行讀寫的時候,cfq才能區(qū)分出IO請求來自哪個進(jìn)程.

所以,除了針對每個進(jìn)程實(shí)現(xiàn)的IO隊(duì)列以外,還實(shí)現(xiàn)了一個公共的隊(duì)列用來處理異步請求.

當(dāng)前內(nèi)核已經(jīng)實(shí)現(xiàn)了針對IO資源的cgroup資源隔離,所以在以上體系的基礎(chǔ)上,cfq也實(shí)現(xiàn)了針對cgroup的調(diào)度支持.關(guān)于cgroup的blkio功能的描述,請看我之前的文章Cgroup – Linux的IO資源隔離.

總的來說,cfq用了一系列的數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)了以上所有復(fù)雜功能的支持,大家可以通過源代碼看到其相關(guān)實(shí)現(xiàn),文件在源代碼目錄下的block/cfq-iosched.c.

1.1 cfq設(shè)計(jì)原理

在此,我們對整體數(shù)據(jù)結(jié)構(gòu)做一個簡要描述：首先,cfq通過一個叫做cfq_data的數(shù)據(jù)結(jié)構(gòu)維護(hù)了整個調(diào)度器流程.在一個支持了cgroup功能的cfq中,全部進(jìn)程被分成了若干個contral group進(jìn)行管理.

每個cgroup在cfq中都有一個cfq_group的結(jié)構(gòu)進(jìn)行描述,所有的cgroup都被作為一個調(diào)度對象放進(jìn)一個紅黑樹中,并以vdisktime為key進(jìn)行排序.

vdisktime這個時間紀(jì)錄的是當(dāng)前cgroup所占用的io時間,每次對cgroup進(jìn)行調(diào)度時,總是通過紅黑樹選擇當(dāng)前vdisktime時間最少的cgroup進(jìn)行處理,以保證所有cgroups之間的IO資源占用“公平”.

當(dāng)然我們知道,cgroup是可以對blkio進(jìn)行資源比例分配的,其作用原理就是,分配比例大的cgroup占用vdisktime時間增長較慢,分配比例小的vdisktime時間增長較快,快慢與分配比例成正比.

這樣就做到了不同的cgroup分配的IO比例不一樣,并且在cfq的角度看來依然是“公平“的.

選擇好了需要處理的cgroup(cfq_group)之后,調(diào)度器需要決策選擇下一步的service_tree.

service_tree這個數(shù)據(jù)結(jié)構(gòu)對應(yīng)的都是一系列的紅黑樹,主要目的是用來實(shí)現(xiàn)請求優(yōu)先級分類的,就是RT、BE、IDLE的分類.每一個cfq_group都維護(hù)了7個service_trees,其定義如下：

其中service_tree_idle就是用來給IDLE類型的請求進(jìn)行排隊(duì)用的紅黑樹.

而上面二維數(shù)組,首先第一個維度針對RT和BE分別各實(shí)現(xiàn)了一個數(shù)組,每一個數(shù)組中都維護(hù)了三個紅黑樹,分別對應(yīng)三種不同子類型的請求,分別是：SYNC、SYNC_NOIDLE以及ASYNC.

我們可以認(rèn)為SYNC相當(dāng)于SYNC_IDLE并與SYNC_NOIDLE對應(yīng).idling是cfq在設(shè)計(jì)上為了盡量合并連續(xù)的IO請求以達(dá)到提高吞吐量的目的而加入的機(jī)制,我們可以理解為是一種“空轉(zhuǎn)”等待機(jī)制.

空轉(zhuǎn)是指,當(dāng)一個隊(duì)列處理一個請求結(jié)束后,會在發(fā)生調(diào)度之前空等一小會時間,如果下一個請求到來,則可以減少磁頭尋址,繼續(xù)處理順序的IO請求.

為了實(shí)現(xiàn)這個功能,cfq在service_tree這層數(shù)據(jù)結(jié)構(gòu)這實(shí)現(xiàn)了SYNC隊(duì)列,如果請求是同步順序請求,就入隊(duì)這個service tree,如果請求是同步隨機(jī)請求,則入隊(duì)SYNC_NOIDLE隊(duì)列,以判斷下一個請求是否是順序請求.

所有的異步寫操作請求將入隊(duì)ASYNC的service tree,并且針對這個隊(duì)列沒有空轉(zhuǎn)等待機(jī)制.

此外,cfq還對SSD這樣的硬盤有特殊調(diào)整,當(dāng)cfq發(fā)現(xiàn)存儲設(shè)備是一個ssd硬盤這樣的隊(duì)列深度更大的設(shè)備時,所有針對單獨(dú)隊(duì)列的空轉(zhuǎn)都將不生效,所有的IO請求都將入隊(duì)SYNC_NOIDLE這個service tree.

每一個service tree都對應(yīng)了若干個cfq_queue隊(duì)列,每個cfq_queue隊(duì)列對應(yīng)一個進(jìn)程,這個我們后續(xù)再詳細(xì)說明.

cfq_group還維護(hù)了一個在cgroup內(nèi)部所有進(jìn)程公用的異步IO請求隊(duì)列,其結(jié)構(gòu)如下：

異步請求也分成了RT、BE、IDLE這三類進(jìn)行處理,每一類對應(yīng)一個cfq_queue進(jìn)行排隊(duì).

BE和RT也實(shí)現(xiàn)了優(yōu)先級的支持,每一個類型有IOPRIO_BE_NR這么多個優(yōu)先級,這個值定義為8,數(shù)組下標(biāo)為0-7.

我們目前分析的內(nèi)核代碼版本為Linux 4.4,可以看出,從cfq的角度來說,已經(jīng)可以實(shí)現(xiàn)異步IO的cgroup支持了,我們需要定義一下這里所謂異步IO的含義,它僅僅表示從內(nèi)存的buffer/cache中的數(shù)據(jù)同步到硬盤的IO請求,而不是aio(man 7 aio)或者linux的native異步io以及l(fā)ibaio機(jī)制,實(shí)際上這些所謂的“異步”IO機(jī)制,在內(nèi)核中都是同步實(shí)現(xiàn)的(本質(zhì)上馮諾伊曼計(jì)算機(jī)沒有真正的“異步”機(jī)制).

我們在上面已經(jīng)說明過,由于進(jìn)程正常情況下都是將數(shù)據(jù)先寫入buffer/cache,所以這種異步IO都是統(tǒng)一由cfq_group中的async請求隊(duì)列處理的.

那么為什么在上面的service_tree中還要實(shí)現(xiàn)和一個ASYNC的類型呢?

這當(dāng)然是為了支持區(qū)分進(jìn)程的異步IO并使之可以“完全公平”做準(zhǔn)備嘍.

實(shí)際上在最新的cgroup v2的blkio體系中,內(nèi)核已經(jīng)支持了針對buffer IO的cgroup限速支持,而以上這些可能容易混淆的一堆類型,都是在新的體系下需要用到的類型標(biāo)記.

新體系的復(fù)雜度更高了,功能也更加強(qiáng)大,但是大家先不要著急,正式的cgroup v2體系,在Linux 4.5發(fā)布的時候會正式跟大家見面.

我們繼續(xù)選擇service_tree的過程,三種優(yōu)先級類型的service_tree的選擇就是根據(jù)類型的優(yōu)先級來做選擇的,RT優(yōu)先級最高,BE其次,IDLE最低.就是說,RT里有,就會一直處理RT,RT沒了再處理BE.

每個service_tree對應(yīng)一個元素為cfq_queue排隊(duì)的紅黑樹,而每個cfq_queue就是內(nèi)核為進(jìn)程(線程)創(chuàng)建的請求隊(duì)列.

每一個cfq_queue都會維護(hù)一個rb_key的變量,這個變量實(shí)際上就是這個隊(duì)列的IO服務(wù)時間(service time).

這里還是通過紅黑樹找到service time時間最短的那個cfq_queue進(jìn)行服務(wù),以保證“完全公平”.

選擇好了cfq_queue之后,就要開始處理這個隊(duì)列里的IO請求了.這里的調(diào)度方式基本跟deadline類似.

cfq_queue會對進(jìn)入隊(duì)列的每一個請求進(jìn)行兩次入隊(duì),一個放進(jìn)fifo中,另一個放進(jìn)按訪問扇區(qū)順序作為key的紅黑樹中.

默認(rèn)從紅黑樹中取請求進(jìn)行處理,當(dāng)請求的延時時間達(dá)到deadline時,就從紅黑樹中取等待時間最長的進(jìn)行處理,以保證請求不被餓死.

這就是整個cfq的調(diào)度流程,當(dāng)然其中還有很多細(xì)枝末節(jié)沒有交代,比如合并處理以及順序處理等等.

1.2 cfq的參數(shù)調(diào)整

理解整個調(diào)度流程有助于我們決策如何調(diào)整cfq的相關(guān)參數(shù).所有cfq的可調(diào)參數(shù)都可以在/sys/class/block/sda/queue/iosched/目錄下找到,當(dāng)然,在你的系統(tǒng)上,請將sda替換為相應(yīng)的磁盤名稱.我們來看一下都有什么：

這些參數(shù)部分是跟機(jī)械硬盤磁頭尋道方式有關(guān)的,如果其說明你看不懂,請先補(bǔ)充相關(guān)知識：

back_seek_max:磁頭可以向后尋址的最大范圍,默認(rèn)值為16M.

back_seek_penalty:向后尋址的懲罰系數(shù).這個值是跟向前尋址進(jìn)行比較的.

以上兩個是為了防止磁頭尋道發(fā)生抖動而導(dǎo)致尋址過慢而設(shè)置的.基本思路是這樣,一個io請求到來的時候,cfq會根據(jù)其尋址位置預(yù)估一下其磁頭尋道成本.

1. 設(shè)置一個最大值back_seek_max,對于請求所訪問的扇區(qū)號在磁頭后方的請求,只要尋址范圍沒有超過這個值,cfq會像向前尋址的請求一樣處理它.
2. 再設(shè)置一個評估成本的系數(shù)back_seek_penalty,相對于磁頭向前尋址,向后尋址的距離為1/2(1/back_seek_penalty)時,cfq認(rèn)為這兩個請求尋址的代價是相同.

這兩個參數(shù)實(shí)際上是cfq判斷請求合并處理的條件限制,凡事復(fù)合這個條件的請求,都會盡量在本次請求處理的時候一起合并處理.

fifo_expire_async:設(shè)置異步請求的超時時間.

同步請求和異步請求是區(qū)分不同隊(duì)列處理的,cfq在調(diào)度的時候一般情況都會優(yōu)先處理同步請求,之后再處理異步請求,除非異步請求符合上述合并處理的條件限制范圍內(nèi).

當(dāng)本進(jìn)程的隊(duì)列被調(diào)度時,cfq會優(yōu)先檢查是否有異步請求超時,就是超過fifo_expire_async參數(shù)的限制.如果有,則優(yōu)先發(fā)送一個超時的請求,其余請求仍然按照優(yōu)先級以及扇區(qū)編號大小來處理.

fifo_expire_sync:這個參數(shù)跟上面的類似,區(qū)別是用來設(shè)置同步請求的超時時間.

slice_idle:參數(shù)設(shè)置了一個等待時間.這讓cfq在切換cfq_queue或service tree的時候等待一段時間,目的是提高機(jī)械硬盤的吞吐量.

一般情況下,來自同一個cfq_queue或者service tree的IO請求的尋址局部性更好,所以這樣可以減少磁盤的尋址次數(shù).這個值在機(jī)械硬盤上默認(rèn)為非零.

當(dāng)然在固態(tài)硬盤或者硬RAID設(shè)備上設(shè)置這個值為非零會降低存儲的效率,因?yàn)楣虘B(tài)硬盤沒有磁頭尋址這個概念,所以在這樣的設(shè)備上應(yīng)該設(shè)置為0,關(guān)閉此功能.

group_idle:這個參數(shù)也跟上一個參數(shù)類似,區(qū)別是當(dāng)cfq要切換cfq_group的時候會等待一段時間.

在cgroup的場景下,如果我們沿用slice_idle的方式,那么空轉(zhuǎn)等待可能會在cgroup組內(nèi)每個進(jìn)程的cfq_queue切換時發(fā)生.

這樣會如果這個進(jìn)程一直有請求要處理的話,那么直到這個cgroup的配額被耗盡,同組中的其它進(jìn)程也可能無法被調(diào)度到.這樣會導(dǎo)致同組中的其它進(jìn)程餓死而產(chǎn)生IO性能瓶頸.

在這種情況下,我們可以將slice_idle ＝ 0而group_idle ＝ 8.這樣空轉(zhuǎn)等待就是以cgroup為單位進(jìn)行的,而不是以cfq_queue的進(jìn)程為單位進(jìn)行,以防止上述問題產(chǎn)生.

low_latency:這個是用來開啟或關(guān)閉cfq的低延時(low latency)模式的開關(guān).

當(dāng)這個開關(guān)打開時,cfq將會根據(jù)target_latency的參數(shù)設(shè)置來對每一個進(jìn)程的分片時間(slice time)進(jìn)行重新計(jì)算.

這將有利于對吞吐量的公平(默認(rèn)是對時間片分配的公平).

關(guān)閉這個參數(shù)(設(shè)置為0)將忽略target_latency的值.這將使系統(tǒng)中的進(jìn)程完全按照時間片方式進(jìn)行IO資源分配.這個開關(guān)默認(rèn)是打開的.

我們已經(jīng)知道cfq設(shè)計(jì)上有“空轉(zhuǎn)”(idling)這個概念,目的是為了可以讓連續(xù)的讀寫操作盡可能多的合并處理,減少磁頭的尋址操作以便增大吞吐量.

如果有進(jìn)程總是很快的進(jìn)行順序讀寫,那么它將因?yàn)閏fq的空轉(zhuǎn)等待命中率很高而導(dǎo)致其它需要處理IO的進(jìn)程響應(yīng)速度下降,如果另一個需要調(diào)度的進(jìn)程不會發(fā)出大量順序IO行為的話,系統(tǒng)中不同進(jìn)程IO吞吐量的表現(xiàn)就會很不均衡.

就比如,系統(tǒng)內(nèi)存的cache中有很多臟頁要寫回時,桌面又要打開一個瀏覽器進(jìn)行操作,這時臟頁寫回的后臺行為就很可能會大量命中空轉(zhuǎn)時間,而導(dǎo)致瀏覽器的小量IO一直等待,讓用戶感覺瀏覽器運(yùn)行響應(yīng)速度變慢.

這個low_latency主要是對這種情況進(jìn)行優(yōu)化的選項(xiàng),當(dāng)其打開時,系統(tǒng)會根據(jù)target_latency的配置對因?yàn)槊锌辙D(zhuǎn)而大量占用IO吞吐量的進(jìn)程進(jìn)行限制,以達(dá)到不同進(jìn)程IO占用的吞吐量的相對均衡.這個開關(guān)比較合適在類似桌面應(yīng)用的場景下打開.

target_latency:當(dāng)low_latency的值為開啟狀態(tài)時,cfq將根據(jù)這個值重新計(jì)算每個進(jìn)程分配的IO時間片長度.

quantum:這個參數(shù)用來設(shè)置每次從cfq_queue中處理多少個IO請求.在一個隊(duì)列處理事件周期中,超過這個數(shù)字的IO請求將不會被處理.這個參數(shù)只對同步的請求有效.

slice_sync:當(dāng)一個cfq_queue隊(duì)列被調(diào)度處理時,它可以被分配的處理總時間是通過這個值來作為一個計(jì)算參數(shù)指定的.公式為：time_slice = slice_sync + (slice_sync/5 * (4 – prio)).這個參數(shù)對同步請求有效.

slice_async:這個值跟上一個類似,區(qū)別是對異步請求有效.

slice_async_rq:這個參數(shù)用來限制在一個slice的時間范圍內(nèi),一個隊(duì)列最多可以處理的異步請求個數(shù).請求被處理的最大個數(shù)還跟相關(guān)進(jìn)程被設(shè)置的io優(yōu)先級有關(guān).

1.3 cfq的IOPS模式

我們已經(jīng)知道,默認(rèn)情況下cfq是以時間片方式支持的帶優(yōu)先級的調(diào)度來保證IO資源占用的公平.

高優(yōu)先級的進(jìn)程將得到更多的時間片長度,而低優(yōu)先級的進(jìn)程時間片相對較小.

當(dāng)我們的存儲是一個高速并且支持NCQ(原生指令隊(duì)列)的設(shè)備的時候,我們最好可以讓其可以從多個cfq隊(duì)列中處理多路的請求,以便提升NCQ的利用率.

此時使用時間片的分配方式分配資源就顯得不合時宜了,因?yàn)榛跁r間片的分配,同一時刻最多能處理的請求隊(duì)列只有一個.

這時,我們需要切換cfq的模式為IOPS模式.切換方式很簡單,就是將slice_idle=0即可.內(nèi)核會自動檢測你的存儲設(shè)備是否支持NCQ,如果支持的話cfq會自動切換為IOPS模式.

另外,在默認(rèn)的基于優(yōu)先級的時間片方式下,我們可以使用ionice命令來調(diào)整進(jìn)程的IO優(yōu)先級.進(jìn)程默認(rèn)分配的IO優(yōu)先級是根據(jù)進(jìn)程的nice值計(jì)算而來的,計(jì)算方法可以在man ionice中看到,這里不再廢話.

2、deadline：最終期限調(diào)度

deadline調(diào)度算法相對cfq要簡單很多.
其設(shè)計(jì)目標(biāo)是：

在保證請求按照設(shè)備扇區(qū)的順序進(jìn)行訪問的同時,兼顧其它請求不被餓死,要在一個最終期限前被調(diào)度到.

我們知道磁頭對磁盤的尋道是可以進(jìn)行順序訪問和隨機(jī)訪問的,因?yàn)閷さ姥訒r時間的關(guān)系,順序訪問時IO的吞吐量更大,隨機(jī)訪問的吞吐量小.

如果我們想為一個機(jī)械硬盤進(jìn)行吞吐量優(yōu)化的話,那么就可以讓調(diào)度器按照盡量復(fù)合順序訪問的IO請求進(jìn)行排序,之后請求以這樣的順序發(fā)送給硬盤,就可以使IO的吞吐量更大.

但是這樣做也有另一個問題,就是如果此時出現(xiàn)了一個請求,它要訪問的磁道離目前磁頭所在磁道很遠(yuǎn),應(yīng)用的請求又大量集中在目前磁道附近.

導(dǎo)致大量請求一直會被合并和插隊(duì)處理,而那個要訪問比較遠(yuǎn)磁道的請求將因?yàn)橐恢辈荒鼙徽{(diào)度而餓死.

deadline就是這樣一種調(diào)度器,能在保證IO最大吞吐量的情況下,盡量使遠(yuǎn)端請求在一個期限內(nèi)被調(diào)度而不被餓死的調(diào)度器.

2.1 deadline設(shè)計(jì)原理

為了實(shí)現(xiàn)上述目標(biāo),deadline調(diào)度器實(shí)現(xiàn)了兩類隊(duì)列,一類負(fù)責(zé)對請求按照訪問扇區(qū)進(jìn)行排序.這個隊(duì)列使用紅黑樹組織,叫做sort_list.另一類對請求的訪問時間進(jìn)行排序.使用鏈表組織,叫做fifo_list.

由于讀寫請求的明顯處理差異,在每一類隊(duì)列中,又按請求的讀寫類型分別分了兩個隊(duì)列,就是說deadline調(diào)度器實(shí)際上有4個隊(duì)列：

1. 按照扇區(qū)訪問順序排序的讀隊(duì)列；
2. 按照扇區(qū)訪問順序排序的寫隊(duì)列；
3. 按照請求時間排序的讀隊(duì)列；
4. 按照請求時間排序的寫隊(duì)列.

deadline之所以要對讀寫隊(duì)列進(jìn)行分離,是因?yàn)橐獙?shí)現(xiàn)讀操作比寫操作更高的優(yōu)先級.

從應(yīng)用的角度來看,讀操作一般都是同步行為,就是說,讀的時候程序一般都要等到數(shù)據(jù)返回后才能做下一步的處理.

而寫操作的同步需求并不明顯,一般程序都可以將數(shù)據(jù)寫到緩存,之后由內(nèi)核負(fù)責(zé)同步到存儲上即可.

所以,對讀操作進(jìn)行優(yōu)化可以明顯的得到收益.當(dāng)然,deadline在這樣的情況下必然要對寫操作會餓死的情況進(jìn)行考慮,保證其不會被餓死.

deadline的入隊(duì)很簡單：當(dāng)一個新的IO請求產(chǎn)生并進(jìn)行了必要的合并操作之后,它在deadline調(diào)度器中會分別按照扇區(qū)順序和請求產(chǎn)生時間分別入隊(duì)sort_list和fifo_list.并再進(jìn)一步根據(jù)請求的讀寫類型入隊(duì)到相應(yīng)的讀或者寫隊(duì)列.

deadline的出隊(duì)處理相對麻煩一點(diǎn)：

1. 首先判斷讀隊(duì)列是否為空,如果讀隊(duì)列不為空并且寫隊(duì)列沒發(fā)生饑餓(starved < writes_starved)則處理讀隊(duì)列,否則處理寫隊(duì)列(第4部).
2. 進(jìn)入讀隊(duì)列處理后,首先檢查fifo_list中是否有超過最終期限(read_expire)的讀請求,如果有則處理該請求以防止被餓死.
3. 如果上一步為假,則處理順序的讀請求以增大吞吐.
4. 如果第1部檢查讀隊(duì)列為空或者寫隊(duì)列處于饑餓狀態(tài),那么應(yīng)該處理寫隊(duì)列.其過程和讀隊(duì)列處理類似.
5. 進(jìn)入寫隊(duì)列處理后,首先檢查fifo_list中是否有超過最終期限(write_expire)的寫請求,如果有則處理該請求以防止被餓死.
6. 如果上一步為假,則處理順序的寫請求以增大吞吐.

整個處理邏輯就是這樣,簡單總結(jié)其原則就是,讀的優(yōu)先級高于寫,達(dá)到deadline時間的請求處理高于順序處理.正常情況下保證順序讀寫,保證吞吐量,有饑餓的情況下處理饑餓.

2.2 deadline的參數(shù)調(diào)整

deadline的可調(diào)參數(shù)相對較少,包括：

read_expire:讀請求的超時時間設(shè)置,單位為ms.當(dāng)一個讀請求入隊(duì)deadline的時候,其過期時間將被設(shè)置為當(dāng)前時間＋read_expire,并放倒fifo_list中進(jìn)行排序.

write_expire:寫請求的超時時間設(shè)置,單位為ms.功能根讀請求類似.

fifo_batch:在順序(sort_list)請求進(jìn)行處理的時候,deadline將以batch為單位進(jìn)行處理.

每一個batch處理的請求個數(shù)為這個參數(shù)所限制的個數(shù).在一個batch處理的過程中,不會產(chǎn)生是否超時的檢查,也就不會產(chǎn)生額外的磁盤尋道時間.

這個參數(shù)可以用來平衡順序處理和饑餓時間的矛盾,當(dāng)饑餓時間需要盡可能的符合預(yù)期的時候,我們可以調(diào)小這個值,以便盡可能多的檢查是否有饑餓產(chǎn)生并及時處理.

增大這個值當(dāng)然也會增大吞吐量,但是會導(dǎo)致處理饑餓請求的延時變長.

writes_starved:這個值是在上述deadline出隊(duì)處理第一步時做檢查用的.用來判斷當(dāng)讀隊(duì)列不為空時,寫隊(duì)列的饑餓程度是否足夠高,以時deadline放棄讀請求的處理而處理寫請求.

當(dāng)檢查存在有寫請求的時候,deadline并不會立即對寫請求進(jìn)行處理,而是給相關(guān)數(shù)據(jù)結(jié)構(gòu)中的starved進(jìn)行累計(jì).

如果這是第一次檢查到有寫請求進(jìn)行處理,那么這個計(jì)數(shù)就為1.如果此時writes_starved值為2,則我們認(rèn)為此時饑餓程度還不足夠高,所以繼續(xù)處理讀請求.

只有當(dāng)starved >= writes_starved的時候,deadline才回去處理寫請求.可以認(rèn)為這個值是用來平衡deadline對讀寫請求處理優(yōu)先級狀態(tài)的,這個值越大,則寫請求越被滯后處理,越小,寫請求就越可以獲得趨近于讀請求的優(yōu)先級.

front_merges:當(dāng)一個新請求進(jìn)入隊(duì)列的時候,如果其請求的扇區(qū)距離當(dāng)前扇區(qū)很近,那么它就是可以被合并處理的.

而這個合并可能有兩種情況：

1. 是向當(dāng)前位置后合并
2. 是向前合并.

在某些場景下,向前合并是不必要的,那么我們就可以通過這個參數(shù)關(guān)閉向前合并.默認(rèn)deadline支持向前合并,設(shè)置為0關(guān)閉.

3、noop調(diào)度器

noop調(diào)度器是最簡單的調(diào)度器.它本質(zhì)上就是一個鏈表實(shí)現(xiàn)的fifo隊(duì)列,并對請求進(jìn)行簡單的合并處理.調(diào)度器本身并沒有提供任何可疑配置的參數(shù).

4、各種調(diào)度器的應(yīng)用場景選擇

根據(jù)以上幾種io調(diào)度算法的分析,我們應(yīng)該能對各種調(diào)度算法的使用場景有一些大致的思路了.

從原理上看,cfq是一種比較通用的調(diào)度算法,它是一種以進(jìn)程為出發(fā)點(diǎn)考慮的調(diào)度算法,保證大家盡量公平.

deadline是一種以提高機(jī)械硬盤吞吐量為思考出發(fā)點(diǎn)的調(diào)度算法,盡量保證在有io請求達(dá)到最終期限的時候進(jìn)行調(diào)度.非常適合業(yè)務(wù)比較單一并且IO壓力比較重的業(yè)務(wù),比如數(shù)據(jù)庫.

而noop呢?其實(shí)如果我們把我們的思考對象拓展到固態(tài)硬盤,那么你就會發(fā)現(xiàn),無論cfq還是deadline,都是針對機(jī)械硬盤的結(jié)構(gòu)進(jìn)行的隊(duì)列算法調(diào)整,而這種調(diào)整對于固態(tài)硬盤來說,完全沒有意義.

對于固態(tài)硬盤來說,IO調(diào)度算法越復(fù)雜,額外要處理的邏輯就越多,效率就越低.

所以,固態(tài)硬盤這種場景下使用noop是最好的,deadline次之,而cfq由于復(fù)雜度的原因,無疑效率最低.

文章出處：Oracle(公眾號ID:OraNews)

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4369.html