對在線真實系統進行性能監控，發現K/V存儲操作并對服務器進行鎖操作。(依舊是限制服務器延遲和吞吐量的主要原因)

服務器I/O 性能仍然很重要。沒有一個高性能的I/O子系統是不可能有好的系統性能的。

奇怪的是, 雖然在過去10年已經看到顯著改善硬件的I / O性能, 但是我們沒有系統I/O性能的飛躍。 所以值得懷疑: 難道依靠標準的商業化操作系統能改善了I/O性能？

商用Linux硬件的簡單I/O測試

這是Simon Peter et al 最近發表的 OSDI 論文的核心問題。

可能我從這篇論文中得到的針對上面那個問題(標準商用操作系統到底有沒有裝備這些I/O的改進？)的最有意思的答案是no:今天，主要的I/O延時障礙在操作系統內核本身。

在一項顯著的實驗中，他們采用商用Linux并嘗試降低對商用硬件上的Redis進行簡單讀寫的延時。

(注意, 這里的“延時”部分很重要 — 我會很快提到。通過多線程改進吞吐量是可行的,問題在于針對特殊請求的延時仍有進步空間, 尤其在數據中心的層面, 延時價值不菲。)

特別地：

• 他們從纜線上接收 1KB 的包。

• 他們對 Redis 進行讀或寫（取決于測試）。

• 他們重復 1000 次，取平均耗時 (讀寫一輪算一次)。

• 他們在商用 Linux 和商用服務器上運行。

  • 例如，價值1200美元的裝備： Dell PowerEdge R520 has Intel x520 10G NIC and Intel RS3 RAID 1GB flash-backed cache, Sandy bridge CPU, 6 cores, 2.2 GHz.

• 他們用 單線程 處理所有數據。

結果很明顯:

讀 (在內存中):

寫 (持久化數據結構):

需要指出的是在每個測試用例中大約70%的內核時間消耗在了網絡棧(networking stack)中。在更大的有效負載下 ,  這也是幾乎固定的開銷, 因為網絡棧必須為每個包重新調用。這就是說, 如果應用比只向內存寫更加復雜,  應用耗時可能激增。但是網絡耗時將保持不變。

對我來說有趣的是 (盡管我是網絡/操作系統菜鳥)明智的選擇使用單線程延時而非吞吐量作為核心度量衡。

注意，有了單線程延時，內核的花費顯而易見。但是如果有吞吐量和多線程的話，可能會忘記內核的存在 — 我們可能很容易僅僅為了測量每秒請求數的增加，完全丟掉每次請求在內核中花費了 84% 的時間的事實。

這種意義明確的方法很重要：你難以優化未度量的部分。

邁向更少I/O的操作系統并超越

大致理解一次請求有多少時間花費在內核上對于設計和維護規模web服務是有幫助的。

在這一點上，我們對抗延時的主要武器已經是類似管道和多線程的東西了。盡管如此，如果延遲不再是一個問題，考慮一下可能會發生的依然是很有趣的。 比如，我 (一個網絡菜鳥)會考慮是否像 SPDY中的管道棧的東西會更簡單。

論文的其他部分探討了我們可以如何降低那些延時，通過使用這個實驗作為一項叫做Arrakis的操作系統研發的動機。

就我所知的Arrakis核心觀點是，很多內核提供的I/O實際上可以通過商用硬件來提供——比如保護、復用和調度。

換句話說，Arrakis 要把 I/O 從 “控制平臺”中拖出來 (例如,盡可能從內核中拖出來)，放到用戶空間 “數據平臺” (例如，硬件上直接發生的復用，但從來不在內核中發生)。

結果比較理想 — 作者聲稱降低了81%的寫延時和 65%的讀延時。

興奮之余，似乎還有進步空間。比如，要手動配置特定硬件的操作系統，尤其在數據中心層面并不現實。大量的服務斷供都是由配置錯誤導致，讓他們更加不透明無濟于事。

我認為時間會證明這種憂慮是否在現實中有立足之地----我不過是個徹頭徹尾的操作系統菜鳥。

英文原文：84% of a single-threaded 1KB write in Redis is spent in the kernel