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

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《单线程1KB的Redis写操作有84%都是耗费在内核上》，聊聊Redis、单线程，我们一起来看看吧！

对在线真实系统进行性能监控，发现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%的读延时。

兴奋之余，似乎还有进步空间。比如，要手动配置特定硬件的操作系统，尤其在数据中心层面并不现实。大量的服务断供都是由配置错误导致，让他们更加不透明无济于事。

我认为时间会证明这种忧虑是否在现实中有立足之地----我不过是个彻头彻尾的操作系统菜鸟。

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

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于数据库的相关知识，也可关注golang学习网公众号。