在发现云服务器读取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与内存之间的距离。这是一个更复杂的问题，目前我们没有足够的知识，也没有足够的参考资料进行分析。只能把问题留在这里，期待有经验的朋友提供线索。