单线程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%的读延时。

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

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

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

攀枝花网站建设、攀枝花网站运维推广公司-贝锐智能，是专注品牌与效果的网络营销公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：贝锐智能

贝锐智能技术为您推荐以下文章