[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

原文发布于微信公众号 - AlwaysGeek(gh_d0972b1eeb60)

原文发表时间:2018-05-04

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏维C果糖

详述 IntelliJ IDEA 的使用界面

是否还记得在博文“ IntelliJ IDEA 安装目录的核心文件讲解 ”中,这张充满神秘色彩的图片呢?进入她,让咱们一起感受她的魅力吧! 如上图所示,打开 I...

2038
来自专栏老安的博客

vmware api开发之快照管理

1974
来自专栏流柯技术学院

Android APP测试的日志文件抓取

  实时打印的主要有:logcat main,logcat radio,logcat events,tcpdump,还有高通平台的还会有QXDM日志

5671
来自专栏程序员的诗和远方

Mac上搭建一个干净的TensorFlow环境

作为一个小前端,最近想折腾下深度学习方面的东西,这不 TensorFlow 刚发布了 1.0 嘛。于是就想在我的 Mac Book 上跑一跑。

43610
来自专栏FreeBuf

LoadLibrary:一款能够允许Linux程序从DLL文件中加载或调用函数的工具

介绍 今天给大家推荐的这个代码库将允许原生Linux程序从一个WindowsDLL文件中加载或调用功能函数。下面是一个简单的演示示例,我将Windows Def...

3208
来自专栏闪电gogogo的专栏

OpenCV+VS开发环境配置

最近跑C程序,头文件中用到了OpenCV中的文件,找了很多篇OpenCV+VS的环境配置,发现如下这篇写的最为详细,特转载来自己的博客中留存,并附上原博客地址如...

1763
来自专栏乐沙弥的世界

Oracle DB Time 解读

Oracle DB Time是Oracle数据库在时间维度上剖析性能的一个重要指标,通过逐级分解该指标,定位到浪费资源或者资源争用的首要事件上,从而通过减少等待...

1001
来自专栏假装我会写代码

两个非常棒的 Laravel 权限管理包推荐

5163
来自专栏小詹同学

Python系列之——手把手教你玩Pycharm

刚入门python的时候,一直觉得用哪个编辑器并没有差别,然而前两天发了一篇文章【Python系列之——如何每天跟女朋友说晚安~】,跟几个粉丝小伙伴在群里一起讨...

2322
来自专栏数据和云

ProxySQL!像C罗一样的强大!

作者 | 张甦, 数据库领域的专家和知名人士、图书《MySQL王者晋级之路》作者,51CTO 专家博主。近10年互联网线上处理及培训经验,专注于 MySQL 数...

3104

扫码关注云+社区

领取腾讯云代金券