监控在线真实系统的性能，发现K/V存储操作并在服务器上执行锁操作。（仍然是限制服务器延迟和吞吐量的主要原因）服务器I/O性能仍然很重要。没有高性能I/O子系统就不可能有良好的系统性能。奇怪的是，虽然过去10年硬件I/O性能有了显着提高，但系统I/O性能却没有飞跃。所以值得怀疑的是：依赖标准的商业操作系统是否可以提高I/O性能？商品Linux硬件上的简单I/O测试这是SimonPeter等人最近发表的OSDI论文中的核心问题。对于上述问题（标准商业操作系统是否配备了这些I/O改进？），我从这篇论文中得到的最有趣的答案可能是否定的：今天，主要的I/O延迟障碍是操作系统内核本身。在一项著名的实验中，他们使用商用Linux并试图减少在商用硬件上对Redis进行简单读写的延迟。（请注意，这里的“延迟”部分很重要——我很快就会讲到。可以通过多线程提高吞吐量，问题是特定请求的延迟仍有改进空间，尤其是在数据中心级，延迟是昂贵的。）具体来说：他们通过线路接收1KB的数据包。他们读取或写入Redis（取决于测试）。他们重复1000次取平均耗时（一轮读写算一次）。它们在商用Linux和商用服务器上运行。例如，价值1200美元的设备：DellPowerEdgeR520具有Intelx52010GNIC和IntelRS3RAID1GB闪存支持缓存，SandybridgeCPU，6核，2.2GHz。他们用一个线程处理所有数据。结果一目了然：读取（内存中）：写入（持久数据结构）：需要注意的是，在每个测试用例中，大约70%的内核时间花在了网络堆栈上。在较大的有效负载下，这也是几乎恒定的开销，因为必须为每个数据包重新调用网络堆栈。也就是说，如果应用程序比仅仅写入内存更复杂，那么应用程序时间可能会激增。但网络时间将保持不变。对我来说有趣的是（即使我是网络/操作系统菜鸟）是使用每线程延迟而不是吞吐量作为核心指标的明智选择。请注意，对于单线程延迟，内核的成本是显而易见的。但如果有吞吐量和多线程，就有可能忘记核心的存在——我们很容易完全忘记每个请求花费84%的时间在核心中只是为了衡量数量增加的事实每秒请求数。这种有意义的方法很重要：很难优化您不衡量的内容。转向更少的I/O操作系统并超越大致了解请求在内核中花费的时间有助于大规模设计和维护Web服务。在这一点上，我们对抗延迟的主要武器已经是流水线和多线程。不过，考虑一下如果延迟不再是问题会发生什么，还是很有趣的。例如，我（一个web菜鸟）会考虑是否像SPDY中的管道栈这样的东西会更简单。本文的其余部分探讨了我们如何通过使用这个实验作为开发名为Arrakis的操作系统的动机来减少这些延迟。据我所知，Arrakis的核心点在于，内核提供的很多I/O实际上可以由商品硬件提供——比如保护、多路复用和调度。换句话说，Arrakis正在将I/O从“控制平面”（例如，尽可能多地从内核）拉到用户空间“数据平面”（例如，多路复用直接发生在硬件上，但从未发生在内核）。结果很有希望——作者声称写入延迟减少了81%，读取延迟减少了65%。兴奋之余，似乎还有进步的空间。例如，手动配置特定硬件的操作系统是不切实际的，尤其是在数据中心级别。大量服务中断是由错误配置引起的，使它们更加不透明也于事无补。我认为时间会证明这种担忧是否在现实中站稳脚跟——我只是一个彻头彻尾的操作系统菜鸟。原文：Redis单线程1KB写入84%花在了内核
