单线程1KB的Redis写操作有84%都是耗费在内核上
对在线真实系统进行性能监控，发现K/V存储操作并对服务器进行锁操作。(依旧是限制服务器延迟和吞吐量的主要原因)
服务器I/O 性能仍然很重要。没有一个高性能的I/O子系统是不可能有好的系统性能的。
奇怪的是, 虽然在过去10年已经看到显著改善硬件的I / O性能, 但是我们没有系统I/O性能的飞跃。 所以值得怀疑: 难道依靠标准的商业化操作系统能改善了I/O性能？
商用Linux硬件的简单I/O测试
这是Simon Peter et al 最近发表的 OSDI 论文的核心问题。
可能我从这篇论文中得到的针对上面那个问题(标准商用操作系统到底有没有装备这些I/O的改进？)的最有意思的答案是no:今天，主要的I/O延时障碍在操作系统内核本身。
在一项显著的实验中，他们采用商用Linux并尝试降低对商用硬件上的Redis进行简单读写的延时。
(注意, 这里的“延时”部分很重要 — 我会很快提到。通过多线程改进吞吐量是可行的,问题在于针对特殊请求的延时仍有进步空间, 尤其在数据中心的层面, 延时价值不菲。)
特别地：
-
他们从缆线上接收 1KB 的包。
-
他们对 Redis 进行读或写（取决于测试）。
-
他们重复 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.
-
-
他们用单线程处理所有数据。
结果很明显:
读 (在内存中):
写 (持久化数据结构):
需要指出的是在每个测试用例中大约70%的内核时间消耗在了网络栈(networking stack)中。在更大的有效负载下 , 这也是几乎固定的开销, 因为网络栈必须为每个包重新调用。这就是说, 如果应用比只向内存写更加复杂, 应用耗时可能激增。但是网络耗时将保持不变。
对我来说有趣的是 (尽管我是网络/操作系统菜鸟)明智的选择使用单线程延时而非吞吐量作为核心度量衡。
注意，有了单线程延时，内核的花费显而易见。但是如果有吞吐量和多线程的话，可能会忘记内核的存在 — 我们可能很容易仅仅为了测量每秒请求数的增加，完全丢掉每次请求在内核中花费了 84% 的时间的事实。
这种意义明确的方法很重要：你难以优化未度量的部分。
迈向更少I/O的操作系统并超越
大致理解一次请求有多少时间花费在内核上对于设计和维护规模web服务是有帮助的。
在这一点上，我们对抗延时的主要武器已经是类似管道和多线程的东西了。尽管如此，如果延迟不再是一个问题，考虑一下可能会发生的依然是很有趣的。 比如，我 (一个网络菜鸟)会考虑是否像 SPDY中的管道栈的东西会更简单。
论文的其他部分探讨了我们可以如何降低那些延时，通过使用这个实验作为一项叫做 Arrakis 的操作系统研发的动机。
就我所知的Arrakis核心观点是，很多内核提供的I/O实际上可以通过商用硬件来提供——比如保护、复用和调度。
换句话说，Arrakis 要把 I/O 从 “控制平台”中拖出来 ( 例如,尽可能从内核中拖出来 )，放到用户空间 “数据平台” ( 例如， 硬件上直接发生的复用，但从来不在内核中发生)。
结果比较理想 — 作者声称降低了81%的写延时和 65%的读延时。
兴奋之余，似乎还有进步空间。比如，要手动配置特定硬件的操作系统，尤其在数据中心层面并不现实。大量的服务断供都是由配置错误导致，让他们更加不透明无济于事。
我认为时间会证明这种忧虑是否在现实中有立足之地----我不过是个彻头彻尾的操作系统菜鸟。
本文转自：开源中国社区 [http://www.oschina.net]
本文标题：单线程 1KB 的 Redis 写操作有 84% 都是耗费在内核上
本文地址：
http://www.oschina.net/translate/kernel-latency 参与翻译： 鑫鑫向融 , 瑞新英文原文： 84% of a single-threaded 1KB write in Redis is spent in the kernel
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
