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

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

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

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

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

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

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

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

特別地：

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

• 他們對 Redis 進行讀或?qū)懀ㄈQ于測試）。

• 他們重復 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.

• 他們用 單線程 處理所有數(shù)據(jù)。

結(jié)果很明顯:

讀 (在內(nèi)存中):

寫 (持久化數(shù)據(jù)結(jié)構):

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

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

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

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

邁向更少I/O的操作系統(tǒng)并超越

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

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

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

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

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

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

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

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

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