i/o scheduler的作用就是為請求佇列裡面的io請求做乙個優化，以此達到提高系統吞吐量、縮短響應時間的目的。更改i/o scheduler有兩種方式：
1./sys/block/device_name/queue/scheduler (ioscheduler); /sys/block/device_name/queue/nr_request(queuesize)
2.永久修改？啟動時，grup->edit->elevator =scheduler_name
但是提高系統吞吐量和縮短響應時間是一件矛盾的事情。因為如果為了提高系統吞吐量，則必然要對io請求的某些順序做改變，這就導致了某些io請求的響應時間增大。而如果為了減小響應時間（那麼就是來乙個請求響應乙個）那麼系統吞吐量或許就會降低了。因此linux有了四種i/o scheduler來滿足不同的情況。
1.cfq(completely fair queuing)
完全公平佇列，實現了請求合併、電梯演算法。每個程序的io請求產生乙個佇列，這個佇列是對尋道位址進行排序，儘量減少尋道時間。每個程序的佇列有自己的優先順序，然後以時間片輪轉的方式去服務每個程序的請求佇列。[1]
2.deadline
這種排程方式實現了請求合併、電梯演算法，然後為每個請求分配乙個超期時間，這樣就避免了某個請求被餓死的情況。在它的實現中分配了好幾個佇列，deadline queue（這個是根據超期時間來排序的），這個是按照磁軌訪問順序來的；write queue；read queue。其中read queue的優先順序比write queue的優先順序高，這主要是因為使用者發出了讀請求後會立馬等待結果，而使用者發出了寫請求後則不會等待他是否完成了（因為使用者看不到）。這三者的優先順序關係是q(read) > q(read) > q(deadline)。大概的響應流程：決定下一次是從佇列中響應哪個請求時，首先是從q(deadline)去檢視第乙個請求是否超期了，如果沒有那麼就會從read或write佇列（這個應該是根據他們之間的優先順序來定的）裡面讀取一批的請求去響應（預設好像是5個）。
3.noop
noop的全稱是no operations，它就是乙個簡單的fifo，不過它實現了合併請求的功能，也就是說如果兩個請求訪問的額磁軌位址在一起，那麼就會合併它們。這種適用於沒有尋到時間的情況，比如說ssd、fusion io，而不適應hdd。
4.as
as其實和cfq差不蠻多，稱作預期的排程，別的io scheduler都只是對離散io做了優化但是並沒有對連續io作優化，比如說乙個io請求剛執行完的這瞬間又在此位置來了乙個io請求，那麼在as這種情況下就可以馬上響應剛才新來的那個請求，它是通過每次完成之後等那麼極短的時間來響應的（6ms？）不過現在已經被cfq取代。www.linuxidc.com 簡單的說：cfq是一種通用方案，deadline適用database情景，而noop適用ssd、fusion io。但是具體的也要看實際情況，比如說deadline只有在極大地io情況下才有可能提公升一定的效能（自己做過測試，規模比較小，沒有多大效能提公升）
下面在談談queue size
queue size就是用來存在io請求的佇列的大小，所以理論上來說queue size越大，提公升的效能更大，因為有更多的請求被優化了。但是這裡需要注意幾種情況。
1. 在ssd、fusion io這種不需要尋道時間（seek time）的情景下，增大了size並沒有多大益處，或許會因為對佇列的維護而帶來負面影響。所以使用之前最好還是測試一下比較合適。
2. 在使用innodb的時候，無論是cfq還是deadline，都不要設定為太大的queue size。有人說innodb內部也對io請求做了根os一樣的優化（實際上應該指的就是insert buffer），那麼如果在os層把queue size設得太大的話會與innodb內部重複，導致額外的代價，效能或許會更低。
3. linux的文件中說deadline比cfq更適合資料庫這種情況，但是貌似只有在極大地系統壓力情況下deadline才會比cfq有比較大的效能優勢。
修改Linux IO排程器
linux系統預設提供了三種io排程方式 原來系統中預設的排程方式是deadline，下面介紹如何更改預設排程機制。通過host cat sys block sdb queue scheduler sdb是我的系統安裝磁碟 noop deadline cfqhost 可以看到預設的排程方式是dead...
Linux IO排程層分析 1
linux io 排程程式是塊裝置 i o子系統的主要元件，它介於通用塊層和塊裝置驅動程式之間，所圖 2 1所示。當 linux 核心元件要讀寫一些資料時，並不是請求一發出，核心便立即執行該請求，而是將其推遲執行。延遲的設定是塊裝置效能的關鍵機制！當傳輸乙個新資料塊時，核心檢查能否通過擴充套件前乙個...
Linux IO排程層分析 2
deadline 演算法維護 5個佇列，除了請求佇列以外，演算法還使用了四個佇列。其中兩個排序佇列分別包含讀請求和寫請求，這個佇列是按照起始扇區數來排序的。另外兩個最後期限佇列包含相同的讀和寫請求，只不過它們是根據其 最後期限 排序的。這兩個佇列的目的是為了避免請求餓死。因為電梯策略優先處理與上乙個...