io排程器（io scheduler）是作業系統用來決定塊裝置上io操作提交順序的方法。存在的目的有兩個，一是提高io吞吐量，二是降低io響應時間。然而io吞吐量和io響應時間往往是矛盾的，為了盡量平衡這兩者，io排程器提供了多種排程演算法來適應不同的io請求場景。其中，對資料庫這種隨機讀寫的場景最有利的演算法是deanline。接著我們按照從簡單到複雜的順序，迅速掃一下linux 2.6核心提供的幾種io排程演算法。
1、noop
noop演算法的全寫為no operation。該演算法實現了最最簡單的fifo佇列，所有io請求大致按照先來後到的順序進行操作。之所以說「大致」，原因是noop在fifo的基礎上還做了相鄰io請求的合併，並不是完完全全按照先進先出的規則滿足io請求。
假設有如下的io請求序列：
100，500，101，10，56，1000
noop將會按照如下順序滿足：
100(101)，500，10，56，1000
2、cfq
cfq演算法的全寫為completely fair queuing。該演算法的特點是按照io請求的位址進行排序，而不是按照先來後到的順序來進行響應。
假設有如下的io請求序列：
100，500，101，10，56，1000
cfq將會按照如下順序滿足：
100，101，500，1000，10，56
在傳統的sas盤上，磁碟尋道花去了絕大多數的io響應時間。cfq的出發點是對io位址進行排序，以盡量少的磁碟旋轉次數來滿足盡可能多的io請求。在cfq演算法下，sas盤的吞吐量大大提高了。但是相比於noop的缺點是，先來的io請求並不一定能被滿足，可能會出現餓死的情況。
3、deadline
deadline在cfq的基礎上，解決了io請求餓死的極端情況。除了cfq本身具有的io排序佇列之外，deadline額外分別為讀io和寫io提供了fifo佇列。讀fifo佇列的最大等待時間為500ms，寫fifo佇列的最大等待時間為5s。fifo佇列內的io請求優先順序要比cfq佇列中的高，，而讀fifo佇列的優先順序又比寫fifo佇列的優先順序高。優先順序可以表示如下：
fifo(read) > fifo(write) > cfq
4、anticipatory
cfq和deadline考慮的焦點在於滿足零散io請求上。對於連續的io請求，比如順序讀，並沒有做優化。為了滿足隨機io和順序io混合的場景，linux還支援anticipatory排程演算法。anticipatory的在deadline的基礎上，為每個讀io都設定了6ms的等待時間視窗。如果在這6ms內os收到了相鄰位置的讀io請求，就可以立即滿足。
io排程器演算法的選擇，既取決於硬體特徵，也取決於應用場景。
在傳統的sas盤上，cfq、deadline、anticipatory都是不錯的選擇；對於專屬的資料庫伺服器，deadline的吞吐量和響應時間都表現良好。然而在新興的固態硬碟比如ssd、fusion io上，最簡單的noop反而可能是最好的演算法，因為其他三個演算法的優化是基於縮短尋道時間的，而固態硬碟沒有所謂的尋道時間且io響應時間非常短。
檢視和修改io排程器的演算法非常簡單。假設我們要對sda進行操作，如下所示：
cat /sys/block/sda/queue/scheduler
echo 「cfq」 > /sys/block/sda/queue/scheduler
修改Linux IO排程器
linux系統預設提供了三種io排程方式 原來系統中預設的排程方式是deadline，下面介紹如何更改預設排程機制。通過host cat sys block sdb queue scheduler sdb是我的系統安裝磁碟 noop deadline cfqhost 可以看到預設的排程方式是dead...
程序排程與排程器及演算法
核心v2.6.23之後 程序的優先順序 總結linux核心的三種 排程策略 sched other 分時排程策略，預設的 sched fifo實時排程策略，先到先服務 sched rr實時排程策略，時間片輪轉 linux 程序排程有乙個有趣歷史。在 2.5 版本之前，linux 核心採用傳統 uni...
實時排程及相關演算法
引言 隨著計算機的發展，多道程式處理的出現需要強大的排程演算法來對多工進行排程，以確定多工環境下任務的執行順序以及占有 cpu 時間。相對於靜態 不可搶占的排程方法，edf 的出現使之憑藉靈活性高 cpu 占有率高很快成為最優的單處理器排程演算法。實時系統是那些時間因素非常關鍵的系統。例如，計算機的...