雲計算之路-阿裡雲上：基于Xen的IO模型進一步分析“黑色0.1秒”問題

　　在雲伺服器讀取OCS緩存的“黑色0.1秒”是發生在socket讀取資料時，而且是發生在讀取開始的位元組，甚至在socket寫資料時（比如寫入緩存key）也會出現超過50ms的情況，我們的好奇心被激發到一個新的高度。

　　根據我們的實測，在雲伺服器上建立一個新的TCP連接配接通常也不過3ms左右。在黑色0.1秒期間，TCP包已經到達網卡，從網卡讀到記憶體中竟然超過100ms，這太不可思議了！後來想想，如果.Net或Windows存在這樣的問題，那微軟就不是全球第一大軟體公司，而是全球第一大忽悠公司，這個可能性真的非常非常小。

　　是以，我們覺得“黑色0.1秒”問題最大的懷疑對象依然是阿裡雲的Xen虛拟機。再加上之前，最大的懷疑對象也是Xen。如果真的是Xen的問題，那就不僅僅是阿裡雲的問題，這讓我們的好奇心更上了一層樓。

　　既然“黑色0.1秒”發生在Xen的網絡IO層面，那我們還等什麼，趕緊去了解Xen的IO虛拟化機制！

　　通過Google很快搜尋到一篇關于Xen的重要論文——：

　　這篇論文的“3.1 Xen”第2段文字專門講到了Xen的IO模型：

3.1 Xen The latest version of the Xen architecture introduces a new I/O model, where special privileged virtual machines called driver domains own specific hardware devices and run their I/O device drivers. All other domains (guest domains in Xen terminology) run a simple device driver that communicates via the device channel mechanism with the driver domain to access the real hardware devices. Driver domains directly access hardware devices that they own; however, interrupts from these devices are first handled by the VMM which then notifies the corresponding driver domain through virtual interrupts delivered over the event mechanism. The guest domain exchanges service requests and responses with the driver domain over an I/O descriptor ring in the device channel. An asynchronous inter-domain event mechanism is used to send notification of queued messages. To support high-performance devices, references to page-sized buffers are transferred over the I/O descriptor ring rather than actual I/O data (the latter would require copying). When data is sent by the guest domain, Xen uses a sharing mechanism where the guest domain permits the driver domain to map the page with the data and pin it for DMA by the device. When data is sent by the driver domain to the guest domain, Xen uses a page-remapping mechanism which maps the page with the data into the guest domain in exchange for an unused page provided by the guest domain.

　　虛拟機的世界果然不一樣。原來在Xen中，每一個實體裝置都有一個專門的特權虛拟機（driver domain）在管理，其他虛拟機（guest

domain，雲伺服器就運作于guest domain）通路實體裝置都要通過對應的driver domain。driver

domain上運作着直接可以通路實體裝置的驅動程式；而guest domain中的驅動程式相當于隻是一個中介，它通過裝置信道機制（device channel

mechanism）與driver domain進行通信，來完成實體裝置的通路操作（見下圖，來自這個PPT——）。（關鍵點1：雲伺服器中的網絡IO操作最終是由driver domain完成的）

　　而來自實體裝置的中斷（interrupt）首先由VMM(Virtual Machine

Monitor)處理，然後基于事件機制，通過相應的虛拟中斷通知相應的driver

domain（關鍵點2：當網卡收到包時，中斷首先是由VMM處理的，然後發給Driver

Domain）。關于這一點，在該論文中的6.1.1節中也提到了：

For each packet received, the network device raises a physical interrupt which is first handled in Xen, and then the appropriate “event” is delivered to the correct driver domain through a virtual interrupt mechanism.

　　當driver domain将來自實體裝置的資料（比如網卡接收到的網絡包）發給guest

domain時，Xen會使用page-remapping（記憶體頁重映射）機制。driver

domain會先将資料從實體裝置讀取到記憶體中，然後将這部分記憶體頁與guest domain中的未使用記憶體頁進行交換，然後guest

domain直接讀取這部分記憶體頁，有點偷梁換柱的味道（關鍵點3：當socket讀取資料時，會進行driver domain與guest

domain的記憶體頁重映射操作）。關于這一點，在該論文的6.1.2節占也提到到了：

For each page of network data received, the page is remapped into the guest domain and the driver domain acquires a replacement page from the guest.

　　再來看看“黑色0.1秒”期間的情況。Wireshark的抓包資料顯示，當時來自OCS的TCP包已經到達guest domain：

　　這說明了什麼呢？先看一張更詳細的Xen I/O架構圖（圖檔來自Xen I/O Overview）：

　　我們推斷，當時TCP包已經到達上圖中的Netfront——guest

domain中的網卡。也就是說實體網卡收到了網絡包，并發出了中斷；中斷被VMM處理并發給了driver domain，driver

domain已經将網卡中的資料讀取到記憶體中；并且已經完成了與guest

domain的page-remapping。socket讀取資料時，實際就是在讀這塊從drvier

domain的remap過來的記憶體頁，就在讀的過程中發生了“黑色0.1秒”。

　　再看一張更詳細的圖（圖檔來自）：

　　在上圖檔中，“黑色0.1秒”就發生在guest domain從Hypervisor Page

Flipping中讀取package data。 

　　通過這次分析，我們覺得問題可能發生在guest

domain從remap過來的記憶體頁中讀取資料時。在這個讀的過程中，不僅涉及記憶體，還要涉及CPU——CPU執行的指令情況，CPU的緩存，CPU與記憶體之間的距離。這是一個更複雜的問題，目前我們沒有足夠的知識，也沒有足夠的參考資料進行分析。隻能把問題留在這裡，期待有經驗的朋友提供線索。