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

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

　　所以，我們覺得“黑色0.1秒”問題最大的懷疑對象依然是阿里云的Xen虛擬機。再加上之前對黑色n秒（n大于1）問題的分析，最大的懷疑對象也是Xen。如果真的是Xen的問題，那就不僅僅是阿里云的問題，這讓我們的好奇心更上了一層樓。

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

　　通過Google很快搜索到一篇關于Xen的重要論文——Diagnosing Performance Overheads in the Xen Virtual Machine Environment：

　　這篇論文的“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——Diagnosing Performance Overheads in the Xen Virtual Machine Environment）。（關鍵點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架構圖（圖片來自[pdf]Xen I/O Overview）：

　　我們推斷，當時TCP包已經到達上圖中的Netfront——guest domain中的網卡。也就是說物理網卡收到了網絡包，并發出了中斷；中斷被VMM處理并發給了driver domain，driver domain已經將網卡中的數據讀取到內存中；并且已經完成了與guest domain的page-remapping。socket讀取數據時，實際就是在讀這塊從drvier domain的remap過來的內存頁，就在讀的過程中發生了“黑色0.1秒”。

　　再看一張更詳細的圖（圖片來自Optimizing Network Virtualization in Xen）：

　　在上圖片中，“黑色0.1秒”就發生在guest domain從Hypervisor Page Flipping中讀取package data。?

　　通過這次分析，我們覺得問題可能發生在guest domain從remap過來的內存頁中讀取數據時。在這個讀的過程中，不僅涉及內存，還要涉及CPU——CPU執行的指令情況，CPU的緩存，CPU與內存之間的距離。這是一個更復雜的問題，目前我們沒有足夠的知識，也沒有足夠的參考資料進行分析。只能把問題留在這里，期待有經驗的朋友提供線索。

轉載于:https://www.cnblogs.com/cmt/p/3723551.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的云计算之路-阿里云上：基于Xen的IO模型进一步分析“黑色0.1秒”问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。