[THP][redis]THP对redis的影响

前言： 前文《[linux][redis]bgsave引起的latency突刺问题分析》分析了redis-server执行bgsave因为fork引起的latency突刺问题。 而在http://antirez.com/news/84中也提到了“However this is definitely not the full story”，剩下的story则是Linux的THP对redis的影响。 分析： 1，THP vs Normal page 配置了THP策略分别是always和never，redis-server和redis-benchmark配置相同的参数，执行bgsave的latency对比：

左图使用了THP，latency最高1ms；右图则没有使用THP，最高latency大约0.3ms。 复现到了“the full story”的另外部分：THP导致的redis-server latency突刺。 2，perf 作者并没有什么好的想法，于是尝试使用perf看看有什么异常。如果自己使用源代码编译的kernel的话，可以到linux/tools/perf目录下执行make，并把编译后的perf复制到/usr/bin目录下可以使用。

默认的perf report结果上来看，并没有看到明显的错误。 换一个策略来看对比结果，看看调用的API是不是有哪些不同： 执行命令：perf report | grep vmlinux | awk '{print $5" "$1}' | sort 继续对比：

发现了copy_huge_pmd、copy_user_huge_page和do_huge_pmd_wp_page等huge page的API只有在THP的情况下调用了。 3，do_huge_pmd_wp_page 分析Linux的源代码，发现在THP的情况下，如果发生了COW： a，发生了page fault b，处理page fault，检查地址，然后确定是因为COW c，执行THP的COW过程，重新分配2M的huge page，并copy数据到新的page上 d，更新page table 梳理过大致流程后，定位在do_huge_pmd_wp_page函数。使用systemtap验证，并计算do_huge_pmd_wp_page执行的时间： global count global tm probe begin { printf("start systemtap ...\n") count = 0 tm = 0 } probe kernel.function("do_huge_pmd_wp_page") { count++ tm = gettimeofday_ns() printf("probefunc : %s, execname : %s, count = %d, tm = %ld\n", probefunc(), execname(), count, tm) //print_backtrace() } probe kernel.function("do_huge_pmd_wp_page").return { tmp_tm = gettimeofday_ns() printf("probefunc : %s, execname : %s, count = %d, tm = %ld, cost = %ld\n", probefunc(), execname(), count, tmp_tm, tmp_tm - tm) //print_backtrace() } 复现现象，观察systemtap的结果： probefunc : do_huge_pmd_wp_page, execname : redis-server, count = 104425, tm = 1525413213918367286 probefunc : __handle_mm_fault, execname : redis-server, count = 104425, tm = 1525413213918620681, cost = 253395 probefunc : do_huge_pmd_wp_page, execname : redis-server, count = 104426, tm = 1525413213918636773 probefunc : __handle_mm_fault, execname : redis-server, count = 104426, tm = 1525413213918892013, cost = 255240 probefunc : do_huge_pmd_wp_page, execname : redis-server, count = 104427, tm = 1525413213918898287 probefunc : __handle_mm_fault, execname : redis-server, count = 104427, tm = 1525413213919144449, cost = 246162 probefunc : do_huge_pmd_wp_page, execname : redis-server, count = 104428, tm = 1525413213919152420 probefunc : __handle_mm_fault, execname : redis-server, count = 104428, tm = 1525413213919397606, cost = 245186 类似的打印可以看到 do_huge_pmd_wp_page的时间成本大约是0.25ms。处理THP的page fault延迟远远大于4k的page fault。那么为什么THP给redis-server带来的平均延迟大于0.25ms呢？ 举例子来说，A，B，C三个请求几乎同时来，redis是单线程模型，就先处理A，A触发了THP fault，处理完成后大约开始处理B，那么B已经有了0.25ms的延迟了。B也可能写了另外一个THP，触发了fault，那么B的延迟就变成了0.5ms。。。 当然，也是存在另外的一种情况的：执行THP fault的时候，发现申请不到2M的page了，就需要把原来的huge page执行split，当然也需要拷贝数据。 4，solution 按照antirez建议： 执行echo never > /sys/kernel/mm/transparent_hugepage/enabled