一场由fork引起的超时，让咱们从新探讨了Redis的抖动问题

摘要：高斯Redis，完全解决原生Redis的fork抖动问题!

背景介绍

在一次支撑客户业务上云的过程当中，发现一次由fork引起的时延抖动问题，经过详细探究了fork这个系统调用的性能影响，而且在最新的GaussDB(for Redis)版本已解决了这个抖动问题，清零了内部的fork使用，与原生Redis相比，完全解决了fork的性能隐患。

问题焦点

· 华为云GaussDB(for Redis)服务在某客户上云线调测过程当中发现，系统上量后规律性的出现每5分钟1次的时延抖动问题。

· 华为云GaussDB(for Redis)团队通过攻关，最终确认抖动缘由是fork致使并解决了这个问题。而fork是开源Redis的一个重要依赖，但愿经过本文的分享，可以帮助你们在使用开源Redis的时候，充分认识fork的影响，从而选择更优的方案。

问题现象

客户业务接入GaussDB(for Redis)压测发现，每5分钟系统出现一次规律性的时延抖动：

· 正常状况消息时延在1-3ms，抖动时刻时延达到300ms左右。

· 一般是压测一段时间后开始出现抖动；抖动一旦出现后就很是规律的保持在每5分钟1次；每次抖动的持续时长在10ms之内。

下图是从系统慢日志中捕获到的发生抖动的消息样例（对敏感信息进行了遮掩）：

问题分析

1）排查抖动源：

· 因为故障的时间分布很是规律，首先排除定时任务的影响，主要包括：

· agent：和管控对接的周期性统计信息上报任务

· 内核：执行引擎（Redis协议解析）和存储引擎（rocksdb）的周期性操做（包括rocskdb统计，wal清理等）

屏蔽上述2类定时任务后，抖动依然存在。

· 排除法未果后，决定回到正向定位的路上来。经过对数据访问路径增长分段耗时统计，最终发现抖动时刻内存操做（包括allocate、memcpy等）的耗时显著变长；基本上长出来的时延，都是阻塞在了内存操做上。

（截图为相关日志，单位是微秒）

· 既然定位到是系统级操做的抖动，那么下一步的思路就是捕获抖动时刻系统是否有异常。咱们采起的方法是，经过脚本定时抓取top信息，分析系统变化。运气比较好，脚本部署后一下就抓到了一个关键信息：每次在抖动的时刻，系统中会出现一个frm-timer进程；该进程为GaussDB(for Redis)进程的子进程，且为瞬时进程，持续1-2s后退出。

· 为了确认该进程的影响，咱们又抓取了perf信息，发如今该进程出现时刻，Kmalloc， memset_sse，memcopy_sse等内核系统调用增多。从上述信息推断，frm-timer进程应该是被fork出来的，抖动源基本可锁定在fork frm-timer这个动做上。

2）肯定引起抖动的代码：

· 分析frm-timer的来历是下一步的关键。由于这个标识符不在咱们的代码中，因此就须要拉通给咱们提供类库的兄弟部门联合分析了。通过你们联合排查，确认frm-timer是日志库liblog中的一个定时器处理线程。若是这个线程fork了一个匿名的子进程，就会复用父进程的线程名，表现为Redis进程建立出1个名为frm-timer的子进程的现象。

· 因为frm-timer负责处理liblog中全部模块的定时器任务，到底是哪一个模块触发了上述fork？这里咱们采起了一个比较巧妙的方法，咱们在定时器处理逻辑中增长了一段代码：若是处理耗时超过30ms，则调用std:: abort()退出，以生成core栈。

· 经过分析core栈，并结合代码排查，最终确认引起抖动的代码以下：

上述代码是用来周期性归档日志的，它每5分钟会执行1次 system系统调用来运行相关脚本，完成归档日志的操做。而Linux system系统调用的源码以下，其实是一个先fork子进程，再调用execl的过程。

· 分析至此，咱们还须要回答最后一个问题：到底是fork致使的抖动，仍是脚本内容致使的抖动？为此，咱们设计了一组测试用例：

· 用例1：将脚本内容改成最简单的echo操做

· 用例2：在Redis进程里模拟1个相似frm-timer的线程，经过命令触发该线程执行fork操做

· 用例3：在Redis进程里模拟1个相似frm-timer的线程，经过命令触发该线程执行先fork，再excel的操做

· 用例4：在Redis进程里模拟1个相似frm-timer的线程，经过命令触发该线程执行system的操做

· 用例5：在Redis进程里模拟1个相似frm-timer的线程，经过命令触发该线程执行先vfork，再excel的操做

最终的验证结果：

· 用例1：有抖动。

· 用例2：有抖动。

· 用例3：有抖动。

· 用例4：有抖动。

· 用例5：无抖动。

用例1结果代表抖动和脚本内容无关；用例二、三、4的结果代表调用system引起抖动的根因是由于其中执行了fork操做；用例5的结果进一步佐证了抖动的根因就是由于fork操做。最终的故障缘由示意图以下：

3）进一步探究fork的影响：

· 众所周知，fork是Linux（严格说是POSIX接口）建立子进程的系统调用，历史上看，主流观点大多对其赞誉有加；但近年间随着技术演进，也陆续出现了反对的声音：有人认为fork是上个时代遗留的产物，在现代操做系统中已通过时，有不少害处。激进的观点甚至认为它应该被完全弃用。（参见附录1,2）

· fork当前被诟病的主要问题之一是它的性能。你们对fork一般的理解是其采用copy-on-wirte写时复制策略，所以对其的性能影响不甚敏感。但实际上，虽然fork时可共享的数据内容不须要复制，但其相关的内核数据结构（包括页目录、页表、vm_area_struc等）的复制开销也是不容忽视的。附录一、2中的文章对fork开销有详细介绍，咱们这回遇到的问题也是一个鲜活的案例：对于Redis这样的时延敏感型应用，1次fork就可能致使消息时延出现100倍的抖动，这对于应用来讲无疑是不可接受的。

4）原生Redis的fork问题：

4.1 原生Redis一样被fork问题困扰（参见附录3，4，5），具体包括以下场景：

1）数据备份

备份时须要生成RDB文件，所以Redis须要触发一次fork。

2）主从同步

全量复制场景（包括初次复制或其余堆积严重的状况），主节点须要产生RDB文件来加速同步，一样须要触发fork。

3）AOF重写

当AOF文件较大，须要合并重写时，也会产生一次fork。

4.2 上述fork问题对原生Redis的影响以下：

1）业务抖动

原生Redis采用单线程架构，若是在电商大促、热点事件等业务高峰时发生上述fork，会致使Redis阻塞，进而对业务形成雪崩的影响。

2）内存利用率只有50%

Fork时子进程须要拷贝父进程的内存空间，虽然是COW，但也要预留足够空间以防不测，所以内存利用率只有50%，也使得成本高了一倍。

3）容量规模影响

为减少fork的影响，生产环境上原生Redis单个进程的最大内存量，一般控制在5G之内，致使原生Redis实例的容量大大受限，没法支撑海量数据。

解决方法

1. 修改日志库liblog中的周期性归档逻辑，再也不fork子进程。
2. 系统排查并整改GaussDB(for Redis)代码（包括使用的类库代码）中的fork调用。
3. 最终排查结果，实际只有本次的这个问题点涉及fork。当前修改后便可确保GaussDB(for Redis)的时延保持稳定，再也不受fork性能影响。

注：GaussDB(for Redis)由华为云基于存算分离架构自主开发，所以不存在原生Redis的fork调用的场景。

总结

本文经过分析GaussDB(for Redis)的一次由fork引起的时延抖动问题，探究了fork这个系统调用的性能影响。最新的GaussDB(for Redis)版本已解决了这个抖动问题，并清零了内部的fork使用，与原生Redis相比，完全解决了fork的性能隐患。但愿经过这个问题的分析，可以带给你们一些启发，方便你们更好的选型。

附：

1.[是时候淘汰对操做系统的 fork() 调用了]

https://www.infoq.cn/article/...

2.[Linux fork那些隐藏的开销]

https://www.mdeditor.tw/pl/29L0

3.[Redis官方文档]

https://redis.io/topics/latency

4.[Redis的一些坑]

https://www.jianshu.com/p/03d...

5.[Redis 常见问题之-fork操做]

https://blog.csdn.net/longgeqiaojie304/article/details/89407214

6.[GaussDB(for Redis)官网连接]

https://www.huaweicloud.com/product/gaussdbforredis.html

本文分享自华为云社区《华为云PB级数据库GaussDB(for Redis)揭秘第三期：一场由fork引起的超时，让咱们从新探讨了Redis的抖动问题》，原文做者：高斯Redis官方博客 。

点击关注，第一时间了解华为云新鲜技术~