Redis在持久化时产生的延迟

一个老外的有关Redis的博客文章中提到一个有趣的事情:它们在测试期间获得的延迟图。为了持久化Redis的数据到磁盘(例如:RDB持久化),Redis需要调用fork()系统命令。 通常使用物理服务器和大多数虚拟机管理程序进行fork是很快的,即使很大的进程也是如此。 然而,Xen的fork()速度很慢,因此对于某些EC2实例类型(以及其他虚拟服务器提供程序),每次父进程调用fork()以便进行RDB持久化时,可能会出现严重的延迟峰值。 如下图所示,清晰的展示了延迟峰值:

stripe-latency.png

您可以想象一下,如果您在fork()的时候做一个延迟测试,那么在父进程fork()的时候,所有请求将延迟一秒(以上图为例)。 这将产生大量具有高延迟的样本,并且将影响99%的结果。

要更改实例类型,配置,设置或其他任何内容以改善此行为是一个好主意,并且有些用例即使单个请求具有过高延迟也是不可接受的。然而很明显的是,每30分钟发生1秒的延迟峰值不是很明显,因为这与在请求中均匀分布延迟峰值有很大不同。

如果是均匀分布的峰值,如果访问某个页面需要对Redis服务器执行大量请求,则访问页面很可能会碰到延迟:这会严重影响服务质量。

然而,如上图所示,每运行30分钟后1秒的延迟是完全不同的事情。具有良好延迟表现的百分比随着请求数量的增加而变得更好,因为请求越多,这个延迟就越不可能在样本中过度表示出来,反而会被隐藏。如果您每分钟只有1个请求,并且其中一个请求恰好碰到fork()导致的高延迟,那就会让延迟测试结果非常难看。

另外:大多数页面浏览不受影响。 因为唯一那几个用户碰到1秒延迟的,是刚好他们的请求和fork()在同一时间,其他用户的请求只会有极低的概率碰到这样糟糕的事情。 另外请注意,与fork()撞上的页面访问(即使由100个请求组成)也不会延迟超过一秒,因为fork()完成后请求就会完成,并不需要等到RDB持久化完成。

只有fork()会导致延迟毛刺,fork出来的子进程在生成RDB文件过程中,并不会对系统有很大的影响。除非子进程生成RDB文件的过程中(这个过程使用了操作系统的copy-on-write机制)有大量的写入,而且服务器可用内存不多,这时候可能会发生swapping导致出现延迟。

在当今最流行的运行时环境EC2实例中,fork延迟是Redis用户最糟糕的体验之一,所以redis作者正着手测试Redis和EC2:相信很快就会在Redis官方文档中有对EC2进行特定优化的说明 ,到时候会有比在master-slaves中禁用持久性操作更安全的方案。

如果您现在需要EC2 + Redis主机并且已禁用持久性,则最简单的部署方式是禁用Redis实例的自动重启,并使用Sentinel进行故障转移,以便崩溃的主服务器不会自动返回可用状态。 在检查故障转移成功并且有新的可用的master后,系统管理员可以手动重新启动实例。

需要说明的是,并非所有EC2实例都是相同的,恰恰相反,各种EC2实例fork表现差异还很大。如下图所示,是老外做的一些测试:

image.png

图片来自:https://redislabs.com/blog/testing-fork-time-on-awsxen-infrastructure/#.VFJQ-JPF8yF

总结

Redis持久化时调用fork可能引起严重的延迟(RDB持久化以及AOF rewrite都会调用fork命令);

只是fork时引起延迟,fork完成后,子进程生成RDB/AOF文件的过程并不会引起延迟;

即使Redis是单线程处理命令,但是服务器配置最好还是需要双核,如果有多个Redis实例,那么核心数相应的翻倍;

除了fork会引起延迟外,Redis中那些时间复杂度为O(n)的也会引起性能毛刺,例如keys命令等。

文章参考:http://antirez.com/news/83

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181025G1I5LE00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券