如何選擇IO調度器

概述

因爲對multi-quque的IO調度算法不太熟悉，爲了不誤人子弟，本文暫時只會介紹如何選擇single-queue的IO調度算法。等未來對multi-queue有充分認識後再補充。

若是不清楚什麼是single-queue和multi-queue，能夠看這文章《塊層介紹 第二篇: request層》

最新版本的Linux內核已經徹底切到multi-queue架構，所以single-queue下的IO調度算法在最新內核可能已經銷聲匿跡了。但實際上，multi-queue的IO調度算法很大程度上參考了single-queue的IO調度算法，所以必定程度上能夠類推。

單隊列調度算法	多隊列調度算法
deadline	mq-deadline
cfq	bfq
noop	none
	kyber

爲何須要IO調度呢？在最開始的時候，Linux存儲在磁盤上。磁盤盤片高速旋轉，經過磁臂的移動讀取數據。磁臂的移動是物理上的機械上的移動，它沒法瞬移，這速度是很慢的。若是咱們讀取的數據位置很隨機，一會在A地點，一會在隔着老遠的B地點，移動的時間就全作了無用功，這也就是咱們說的隨機讀寫性能慢的緣由。若是讀取的數據地址是連續的，即便不是連續的也是地址接近的，那麼移動磁臂的時間損耗就少了。在最開始，IO調度的做用就是爲了合併相近的IO請求，減小磁臂的移動損耗。

單隊列調度算法

單隊列架構下，經常使用的調度算法有3種：noop，deadline和cfq

noop

noop只會對請求作一些簡單的排序，其本質就是一個FIFO的隊列，只會簡單地合併臨近的IO請求後，本質仍是按先來先處理的原則提交給磁盤。

根據它的原理，咱們能夠發現它傾向於餓死讀利於寫，爲何呢？異步寫是把數據直接放到page cache的，也就意味着能夠經過page cache緩存大量的寫數據，再一次性往下提交IO請求。而讀呢？讀通常是同步的，也就意味着必須在讀完一筆後再讀下一筆，兩次讀之間是可能被寫請求插足的。

cfq

CFQ算法會爲每一個進程單首創建一個隊列，保存該進程產生的全部IO請求。不一樣隊列之間按時間片來調度，以此保證每一個進程都能很好的分到I/O帶寬。這IO的時間片調度跟進程調度是很是類似的，進程調度有進程優先級，而IO調度也有IO優先級。

CFQ的出發點是對IO地址進行排序，以儘可能少的磁盤旋轉次數來知足儘量多的IO請求。在CFQ算法下，SAS盤的吞吐量大大提升了。可是相比於NOOP的缺點是，先來的IO請求並不必定能被知足，可能會出現餓死的狀況。

當一個同步隊列中的請求不足必定數量時，這個設備能夠空閒一會，即便其它隊列裏可能有請求等待處理。一般，同步請求之間在磁盤上的物理位置是連續的，因此讓磁盤稍等一會來接收更多連續的請求，這樣作能夠提升吞吐量。

deadline

deadline確保請求在一個用戶可配置的時間內獲得響應，避免請求餓死。其分別爲讀IO和寫IO提供不一樣的FIFO隊列，讀FIFO隊列的最大等待時間是500ms，寫FIFO隊列的最大等待時間是5s。deadline會把提交時間相近的請求放在一批。在同一批中，請求會被排序。當一批請求達到了大小上限或着定時器超時，這批請求就會提交到設備隊列上去。

選擇調度算法

網上的資料基本都給出相似的結論：

1. 對閃存等存儲介質，優先使用noop調度算法
2. 我的PC使用cfq調度算法
3. 對IO壓力比較重，且功能比較單一的場景，例如數據庫服務器，使用deadline調度算法

惋惜的是網上的資料基本是相互複製，不多能講清楚這麼選擇的緣由。

• 爲何閃存等介質，例如固態硬盤SSD，要選擇noop調度算法？
  noop先來先處理的作法對磁盤來講時間損耗很是大，大量浪費了磁盤磁臂移動的時間。可是對閃存設備，例如mmc、nand等，倒是最好的選擇，由於閃存設備的物理結構跟磁盤徹底不一樣，其經過一些規範的命令便可讀取數據，沒有磁臂這東西。此時IO調度算法裏的排序、合併其實沒太大意義，反而浪費了CPU和內存。

• 爲何我的PC要用cfq調度算法？
  在我的PC的場景上，每每須要打開大量的程序，建立大量的進程。每一個進程均可能有IO的請求。在這場景下，咱們須要的是如何確保不一樣進程或進程組間IO資源使用的公平性。總不能由於A進程要拷貝電影，獨佔了IO資源，致使B進程沒法打開文檔不是？
  cfq調度算法是以進程之間公平享用IO資源爲出發點設計的，因此，我的PC建議使用cfq調度算法，但cfq調度算法不只僅用於我的PC，準確來講，cfq調度算法適用於有大量進程的多用戶系統。

• 爲何deadline調度算法適用於數據庫？
  deadline是一種以提升機械硬盤吞吐量爲思考出發點的調度算法，因此準確來講，deadline調度算法適用於IO壓力比較重，且業務功能單一的場景，而數據庫毫無疑問是最爲匹配的場景了。

根據以上描述的不一樣調度算法的特色，咱們再根據本身的場景挑選合適的IO調度算法就好，靈活點，自信點，不要別人說啥就選啥，別人沒說就一臉懵逼。

多隊列調度算法

先留坑，之後填