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

摘要：

Redis 英文原文：84% of a single-threaded 1KB write in Redis is spent in the kernel

对在线真实系统实行功能监控，发明K/V存储操纵并对Server实行锁操纵。(照旧是限礼服务器延迟和吞吐量的首要缘由)

ServerI/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实行容易读写的延时。

(留意, 这里的“延时”部分很主要 — 我会很快提到。经过多线程改良吞吐量是可行的,问题在于针对特别恳求的延时仍有提高空间, 特别在数据中间的层面, 延时值值不菲。)

特殊地：

例如，价值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.

后果很分明:

读 (在内存中):

Redis read

写 (耐久化数据构造):

Redis write

需求指出的是在每一个测试用例中约莫70%的内核工夫耗费在了收集栈(networking stack)中。在更大的有效负载下 , 这也是简直牢固的开支, 由于收集栈必需为每一个包从头挪用。这就是说, 假如使用比只向内存写愈加庞杂, 使用耗时可能激增。可是收集耗时将坚持稳定。

对我来讲风趣的是 (虽然我是收集/操纵系统菜鸟)明智的选择运用单线程延时而非吞吐量作为中心怀抱衡。

留意，有了单线程延时，内核的破费不言而喻。可是假如有吞吐量和多线程的话，可能会遗忘内核的存在 — 我们可能很轻易仅仅为了丈量每秒恳求数的增加，完整丢掉每次恳求在内核中破费了 84% 的工夫的现实。

这类意义明白的办法很主要：你难以优化未怀抱的部分。

大致了解一次恳求有几多工夫破费在内核上关于设计和保护范围web办事是有协助的。

在这一点上，我们对立延时的首要兵器曾经是相似管线和多线程的工具了。假如延时不在话下，思索一下可能发作的工作仍是很有兴趣的。比方，我 (一个收集菜鸟)会思索能否像 SPDY中的管线栈的工具会更容易。

论文的其他部分讨论了我们可以怎么用这个作为一个叫做Arrakis的研发操纵系统念头的试验下降那些延时。

就我所知的Arrakis中心观念是非常多内核供给的I/O实践上可以经过商用硬件来供给——比方维护、复用和调剂。

换句话说，Arrakis 要把 I/O 从 “把持平台”中拖出来 (例如,尽量从内核中拖出来)，放到用户空间 “数据平台” (例如，硬件上间接发作的复用，但历来不在内核中发作)。

后果比拟幻想 — 作者宣称下降了81%的写延时和 65%的读延时。

高兴之余，仿佛另有提高空间。比方，要手动设置装备摆设特定硬件的操纵系统，特别在数据中间层面其实不现实。大量的办事断供都是由设置装备摆设过错招致，让他们愈加不通明杯水车薪。

我以为工夫会证实这类忧愁能否在现实中有立锥之地----我不外是个彻彻底底的操纵系统菜鸟。

本文中的一切译文仅用于进修和交换目标，转载请务必注明文章译者、出处、和本文链接。 2KB翻译任务按照 CC 协定，假如我们的任务有进犯到您的权益，请实时联络我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务