单线程1KB的Redis写操作有84%都是耗费在内核上

发表时间:2015-2-21 18:48:40 | 浏览次数: | 文章作者:匿名

对在线真实系统进行性能监控,发现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%的读延时。
 
兴奋之余,似乎还有进步空间。比如,要手动配置特定硬件的操作系统,尤其在数据中心层面并不现实。大量的服务断供都是由配置错误导致,让他们更加不透明无济于事。
 
我认为时间会证明这种忧虑是否在现实中有立足之地----我不过是个彻头彻尾的操作系统菜鸟。


  • 上一篇文章:
  • 下一篇文章: 没有了

  • 电脑技术交流官网
    分享一切技术信息
    技术宅交流网-电脑技术交流天地