為什麼我們需要調整磁盤I/O scheduling算法？在什麼情況下我們需要考慮調整調度算法？該如何調整？本文將針對上述問題做些回答。
I/O scheduling是操作系統存取數據塊順序的算法規則總稱，某些情況下我們可能更熟悉稱它為 disk scheduling。
出於以下幾個目我們可能會需要考慮調整磁盤的調度算法：
最小化磁盤尋道時間；
優化關鍵進程的I/O請求，保證關鍵進程的I/O請求；
讓服務器上的進程更好的共享I/O帶寬；
在RHEL3版本之前我們只有一個電梯算法可以選擇，由於該算法的局限性因此在之後RHEL4版本，我們有以下4中算法可以選擇：
CFQ-completely fair queuing
NOOP-Noop scheduler，No Operation
Deadline scheduler
Anticipatory scheduling
下面針對上述4個算法逐個了解下具體的算法規則。
首先是CFQ，這個算法是大部分發行的Linux版本中默認采用的算法，全稱為完全公平隊列算法，該算法嘗試公平的把i/o帶寬資源給所有進程，進程提交的請求分別放入各自的隊列（64個隊列），因此同一個進程提交的請求通常會被存放到同一個隊列當中去，在大部分情況下是適用大部分的應用系統。
NOOP，該算法最為簡單，占用最少的CPU調度時間，遵循FIFO-先進先出的原則對I/O請求進行調度，但是也並不總是這樣，因為它還是會對相臨近I/O請求的進程做些合並。在存儲硬件和磁盤較為優化的情況下該算法的信息還是不錯的，比如SSD。
Deadline，最後期限算法，該算法最重要的是避免了CFQ算法中某些請求長時間得不到資源餓死的情況發生。使用了4個隊列，2個讀寫隊列和2個讀寫最後期限隊列，根據他們的過期時間在最後期限隊列排隊。該算法中讀請求優先級高於寫請求，因此首先完成讀請求隊列（除非寫請求已經被放棄、死亡過很多次），接著檢查第1個請求的過期時間，讀請求的過期時間為500ms，寫請求的過期時間為5s，如果檢查到第1個請求的最後期限時間已過，那麼將它移動到隊列末尾。適用於實時請求的系統，推薦數據庫或者web服務器系統使用該算法。
Anticipatory，預期算法，這是最復雜的一種算法，實際上用起來並不是那麼優化，從kernel 2.6.33開始已經被移除了。
通過上部描述推薦而且也有人經過驗證了，針對Oracle數據庫的環境，我們可以優先考慮選擇Deadline算法。
如何查看系統現有使用的調度算法？
cat /sys/block/{DEVICE-NAME}/queue/scheduler
cat /sys/block/sda/queue/scheduler
修改調度算法:
echo {SCHEDULER-NAME} > /sys/block/{DEVICE-NAME}/queue/scheduler
echo noop > /sys/block/hda/queue/scheduler
最後，上述內容都是扯淡，沒有一個算法是最優的，在不同的應用、硬件環境中只有逐個測試才能選擇最適合的算法。
-EOF-