Redis fork适配问题
D系列机型是后续弹性云的主力机型，相对于Redis之前使用的C系列机型或者T系列机型，在cpu、内存、磁盘上都有极大的提升。但在测试过程中，Redis在D系列机型上的性能表现反而不如C系列机型。
测试对比：
| 机器 | 99分位最大值 | 99分位平均值 | fork平均值 | proxy慢日志 |
|---|---|---|---|---|
| D系列机型 | 208ms | 8.77ms | 147ms-159ms | 466940 |
| T系列机型 | 186ms | 10.10ms | 97ms-120ms | 419408 |
在机器配置大幅度提升情况下，fork时常反倒降低，这是不符合常理的。而且fork一直是Redis性能的核心痛点之一，我们从各个维度去优化fork，是不可能容忍fork30%左右的延时提升。
Redis fork源代码
int redisFork() {
int childpid;
long long start = ustime();
if ((childpid = fork()) == 0) {
/* Child */
closeListeningSockets(0);
setupChildSignalHandlers();
} else {
/* Parent */
server.stat_fork_time = ustime()-start;
server.stat_fork_rate = (double) zmalloc_used_memory() * 1000000 / server.stat_fork_time / (1024*1024*1024); /* GB per second. */
latencyAddSampleIfNeeded("fork",server.stat_fork_time/1000);
if (childpid == -1) {
return -1;
}
updateDictResizePolicy();
}
return childpid;
}
Redis fork耗时由stat_fork_time记录，从代码中开出，fork仅仅只是linux层面的耗时，跟Redis应用代码逻辑是毫无关系的。
Linux fork耗时核心开销
fork之后，内核会使用cow机制。当父进程或者子进程对某个页进行写入时，内核会拷贝一份该页的副本，并且会覆盖掉副本页所映射的页表项。这就需要内核能够通过页框找到映射该页的页表以及进程，这也就是反向映射（RMAP）技术。
内核用结构体类型 struct page 对页框进行描述。该结构体的一个成员叫做 mapping；是一个指向结构体类型 address_space 的指针，address_space 类型用于描述该物理页对应的文件对象。其成员包括文件的 inode、用于管理该文件所对应的所有物理页的各种数据结构、以及两个链表（i_mmap 和 i_mmap_shared），链表上存放的每个元素保存了一个进程映射该文件后所得到的虚拟地址信息，采用结构体类型 vm_area_struct（通常简称为 “VMA”）来表示。VMA 提供了一个物理页在一个进程的地址空间中所对应的虚拟地址的信息，根据这些信息可以用于查找正确的页表条目。这样我们就能访问并修改与一个物理页相关的所有页表。
为了进行后续的cow，fork() 需要为进程地址空间中的每个页都添加新的反向映射项，而随着物理页数量的增多操作速度开始变慢，执行速度会显著降低。社区一直在努力试图改进 RMAP 的整体效率。
fork主要在dup_mm() 函数中组织父子进程的匿名线性区反射映射结构anon_vma和anon_vma_chain。
通过抓取fork也从某种程度上说明了这个问题 ：
trace-cmd record -p function_graph -l do_fork -P $YOU_PID
trace-cmd report > result.log
随后根据dup_mm调用，抓取了更多的子函数，查看耗时。
trace-cmd record -p function_graph -l do_fork -l copy_process -l security_task_create -l dup_mm -l wake_up_new_task -l copy_pte_range -l _raw_spin_lock -P $YOU_PID
因为trace-cmd薛定谔抓不准，尝试很多的子函数都被drop掉。但在抓spin_lock的时候，我们开始注意到cpu争抢的问题。
猜测之下，关闭超线程。 脚本：
#!/bin/bash
HYPERTHREADING=1
function toggleHyperThreading() {
for CPU in /sys/devices/system/cpu/cpu[0-9]*; do
CPUID=`basename $CPU | cut -b4-`
echo -en "CPU: $CPUID\t"
[ -e $CPU/online ] && echo "1" > $CPU/online
THREAD1=`cat $CPU/topology/thread_siblings_list | cut -f1 -d,`
if [ $CPUID = $THREAD1 ]; then
echo "-> enable"
[ -e $CPU/online ] && echo "1" > $CPU/online
else
if [ "$HYPERTHREADING" -eq "0" ]; then echo "-> disabled"; else echo "-> enabled"; fi
echo "$HYPERTHREADING" > $CPU/online
fi
done
}
function enabled() {
echo -en "Enabling HyperThreading\n"
HYPERTHREADING=1
toggleHyperThreading
}
function disabled() {
echo -en "Disabling HyperThreading\n"
HYPERTHREADING=0
toggleHyperThreading
}
#
ONLINE=$(cat /sys/devices/system/cpu/online)
OFFLINE=$(cat /sys/devices/system/cpu/offline)
echo "---------------------------------------------------"
echo -en "CPU's online: $ONLINE\t CPU's offline: $OFFLINE\n"
echo "---------------------------------------------------"
while true; do
read -p "Type in e to enable or d disable hyperThreading or q to quit [e/d/q] ?" ed
case $ed in
[Ee]* ) enabled; break;;
[Dd]* ) disabled;exit;;
[Qq]* ) exit;;
* ) echo "Please answer e for enable or d for disable hyperThreading.";;
esac
done
测试一亿数据量：
未关闭超线程：
Thread(s) per core: 2
latest_fork_usec:140700
关闭超线程：
Thread(s) per core: 1
latest_fork_usec:96274
至此定位到cpu问题上。但是我们是不能通过关闭超线程来解决这个问题的。
Cpu cstat、pstat
有了工具，接着我们用 Top-Down模型分析调优。
首先我们自己写程序模拟fork问题，代码如下：
#include <stdlib.h>
#include <sys/time.h>
#include <stdio.h>
#define LEN 1024*768
int main()
{
char *p[LEN];
float time_use = 0;
struct timeval start;
struct timeval end;
unsigned long long i = 0, j = 0;
for(i = 0; i < LEN; i++) {
p[i] = (char *)malloc(4096);
if (p[i] == NULL) {
printf("malloc failed!\n");
return 0;
}
p[i][0] = 0x55;
}
#if 1
while (1) {
for(i = 0; i < LEN; i++)
for(j = 0; j < 4096; j++) {
p[i][j] = (char)rand();
usleep(100);
}
}
#endif
gettimeofday(&start,NULL);
fork();
gettimeofday(&end,NULL);
time_use=(end.tv_sec * 1000000 + end.tv_usec)-(start.tv_sec * 1000000 + start.tv_usec);
printf("time_use is %.10f us\n",time_use);
while(1)
usleep(10);
return 0;
}
虽然在某些机型上呈现出薛定谔的跑不准。不过在验证的机器上，还是明显看到topdown的区别。
名词解释：
Frontend bound（前端依赖）指的是通过CPU预加载、乱序执行技术获得的额外性能。
Backend bound（后端依赖）指的是传统的CPU负责处理事务的能力。由于这一个部分相对其他部分来说，受程序指令的影响更为突出，这一块又划分出了两个分类。core bound（核心依赖）意味着系统将会更多的依赖于微指令的处理能力。memory bound（存储依赖）这里的memory包含了CPU L1～L3缓存的能力和传统的内存性能。
Bad speculation（分支预测错误）这一部分指的是由于CPU乱序执行预测错误导致额外的系统开销。
Retiring（拆卸）字面理解是退休的意思，事实上这里指的是等待指令切换，模块重新初始化的开销。
优化方式：
在前端依赖中，如果iTLB miss率较高，可采用hugepage来进行优化。
如果分支预测开销较大，可以通过编译器参数-funrool-loops来进行优化，也可以对指令进行重新排布，尽量让跳转指令分布在不同的内存区间中；另外使用PGO/FDO进行预编译来提高分支预测的准确率。
在核心依赖中的开销占比可以通过增加计算核心来降低。存储依赖的开销中，如果L1及L2 cache miss率较高，可以更新编译器，使用编译优化参数来减少指令条数。如果是内存的话就可以通过升级内存带宽或者更高频、更低潜伏期的内存来获得性能提升。
Redis是一种后端依赖，可以通过pmu-tools工具进一步确认是存储依赖。C0所有core都会一直占用cache，C1的时候休眠的core是不使用cache的，会释放cache，以此来降低cache miss。
调优结果
Bios调整到c1不降频c1E，勉强到达性能要求。
参考文章
内存回收(匿名页反向映射)
cnblogs.com/Leo_wl/p/5402115.html
Intel CPU 上使用 pmu-tools 进行 TopDown 分析
https://blog.csdn.net/gatieme/article/details/113269052
Top-down Microarchitecture Analysis Method
https://kernel.taobao.org/2019/03/Top-down-Microarchitecture-Analysis-Method/
Top-Down模型分析调优
https://support.huaweicloud.com/tngg-kunpenghpcs/kunpenghpcsolution_05_0030.html
CPU C-states 影响和监测
https://www.aikaiyuan.com/1944.html
What's the reason clear_page_c_e is eating most CPU time here?
https://stackoverflow.com/questions/45417187/whats-the-reason-clear-page-c-e-is-eating-most-cpu-time-here
Avoiding and Identifying False Sharing Among Threads
https://software.intel.com/content/www/us/en/develop/articles/avoiding-and-identifying-false-sharing-among-threads.html
LWN 23732: 虚拟内存之基于对象的反向映射技术
https://mp.weixin.qq.com/s/VyRsgKQjbsW0v0UEr9-c2w
Linux fork那些隐藏的开销
https://mp.weixin.qq.com/s/WzIZbqgahFakPozdeLGRtg
fork()成为负担，需要淘汰
