我之前的一篇文章《非同步io一定更好嗎？》中舉了乙個很**的例子，用以說明在單碟機械式硬碟上非同步io反而可能降低效能的問題，大家的討論很熱烈。前天的nodeparty杭州站分享會上，來自上海的@老趙 隨口帶出了這個問題，大概說是多個非同步io請求會使得效能提高，因為磁頭走到**就處理到**，很多請求在「路上」就可以被處理掉了。
乍一看，我和老趙的結論是相反的。所以從nodeparty回來後查了查資料，並且做了一些實驗，發現這兩種情況在各自特定的場景裡都可能是正確的，在別的場景又都可能是錯誤的。為什麼呢？
我之前的結論沒有認真考慮作業系統對io排程的優化，對此一知半解就拿出來大放厥詞，實在不應該！
linux2.6核心對io排程提供了四種演算法：completely fair queuing（cfq）、deadline、noop和anticipatory（as），詳細情況這裡閱讀。在2.6核心中，系統預設的io排程演算法是cfq，也就是os會對請求的偏移量首先進行排序，按照這個排序順序進行磁頭的移動和請求響應，這正是老趙的觀點的出處。而假如某個磁碟採用了noop的io排程演算法，也就是說核心不會對io排程做任何優化，容易理解，正是我在《非同步io一定更好嗎？》一問中的觀點。除此之外，使用者還可以為不同磁碟指定不同的io排程演算法。檢視某個磁碟的io排程演算法的命令如下：
$[pengchun]$ cat /sys/block/sda/queue/scheduler原文這裡的測試方法不對，已刪掉noop anticipatory deadline [cfq]
總結我的幾點經驗：
1. 非同步io不一定是效能最好的；
2. 作業系統對磁碟io的各種排程演算法中，沒有哪乙個是絕對更好的；隨著應用場景的不同，很可能某乙個演算法的效能遠遠好於其他幾個；而在另外的場景中則相反。例如，某個磁碟專門用來寫日誌的，那麼你用noop就最好了；而如果要作為資料庫的磁碟來使用，deadline可能是最好的演算法了；
3. 儘管作業系統會做這樣那樣的優化，但不要懶惰地依賴作業系統；對機械式磁碟的訪問，盡可能把隨機訪問變成順序訪問。
related posts:
非同步io一定更好嗎？
ireader
PHP原生函式一定好嗎？
今天在閱讀kohana原始碼中的arr類的時候發現了這樣乙個函式 複製 如下 fill an array with a range of numbers.fill an array with values 5,10,15,20 values arr range 5,20 param integer ...
逃避不一定躲得過，面對不一定最難過
國王有七個女兒，這七位美麗的公主是國王的驕傲。她 們那一頭烏黑亮麗的長髮遠近皆知。所以國王送給她們每人一百個漂亮的髮夾。有一天 早上，大公主醒來，一如往常地用髮夾整理她的秀髮，卻發現少了乙個髮夾，於是她偷偷地到了二公主的房裡，拿走了乙個髮夾。二公主發現少了乙個髮夾，便到三公主房裡拿走乙個髮夾 三公主...
到了一定的年紀 就必須要有一定的作為嗎
你的不上進，會帶給孩子一生卑微！全國高考成績開始公布，這是今天最大的熱點。各地狀元的身份，也被 陸續報道。沒有什麼意外，狀元依舊在大城市的超級中學扎堆，家境優渥。比如，貴州的文理科狀元，都是貴陽一中的學生 再比如，四川的高分考生卓汐聰，不僅成績優異，還興趣廣泛 他愛好籃球，課餘，在藝術節中擔任主持，...