加餐01 | 案例分析：怎么解决海量IPVS规则带来的网络延时抖动问题？
该思维导图由 AI 生成，仅供参考
问题的背景
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入分析了在将应用从虚拟机迁移到Kubernetes平台后，出现的网络延时抖动问题，并提供了解决方案。作者首先描述了问题的背景和调试过程，包括使用ebpf进行内核数据包处理过程的时间戳记录和分析，以及通过perf工具定位CPU上的热点函数，最终锁定网络延时问题的过程。文章涉及到Linux内核处理数据包的关键函数、ebpf工具的使用、CPU热点函数的定位等技术细节，为读者提供了解决类似网络延时问题的思路和方法。通过分析，最终发现问题出在IPVS的estimation_timer()函数，由于存在大量的IPVS规则，导致网络超时现象。为了快速解决生产环境上的问题，作者使用内核函数替换成了一个空函数，暂时规避了影响其他softirq的问题。长期的解决方案是将IPVS规则的状态统计从TIMER softirq中转移到kernel thread中处理。整体而言，本文通过深入的案例分析和技术细节，为读者提供了解决类似网络延时问题的宝贵经验和方法。
《容器实战高手课》，新⼈⾸单¥59
全部留言(10)
- 最新
- 精选
closer看了老师的文章涨见识了。深深的知道了自己的不足了，请问一下老师，作为一个运维工程师，怎么学习这种底层的内核开发细节？谢谢老师指导作者回复: @closer, 可以从Linux内核源代码的编译安装开始，然后读一本Linux内核书籍。
2021-01-2939
我来也大集群就容易遇到IPVS规则过多的问题吧。 有点好奇 1. 集群中的其他节点应该也会存在类似的问题吧。 2.每次都是固定在这一个核上做这个事情么？作者回复: @我来也 > 集群中的其他节点应该也会存在类似的问题吧。 是的，在kubernetes cluster里，每个节点都会有同样的问题。ipvs rules是为每个service的in cluster vip设置的，在所有节点上的配置都是一样的。 > 每次都是固定在这一个核上做这个事情么？ 是的，对于timer函数，在哪个cpu核上注册，后面就一直在那个核上执行了。
2021-02-0628
莫名很赞的排查思路。 softirq 通常是节点内网络延迟的重要线索。不借助 eBPF 工具时，可以先采用传统工具 top、mpstat 重点观测下 softirq CPU 使用率是否存在波动或者持续走高的情况。如果存在，进一步使用 perf 进行热点函数分析。 不过使用现有的 eBPF softirq 相关工具更方便。作者回复: @莫名， 这里的问题就是一开始如何就认为是softirq这里出问题。在节点有80核的情况下，简单看一下top里的si， 它的usage是不多的。
2021-01-2925
Joe Black“把 IPVS 规则的状态统计从 TIMER softirq 中转移到 kernel thread 中处理”，这个事情是通过什么配置就可以实现的吗？总不能改内核模块吧？作者回复: 不能通过配置来实现，需要改内核。
2021-02-044
那时刻请问老师，IPVS过多是由于service导致的么？还是旧service遗留导致的呢？ 另外，不知可否分享下您实现的ebpf工具呢？作者回复: @那时刻， 对的IPVS是由于cluster中有大量的service, 不是残留。 我们的ebpf工具和这个有些类似吧。 https://github.com/yadutaf/tracepkt 我们增加了更多的tracepoint点和kprobe点，多了一些event的信息
2021-01-294- Geek_c92584干货满满，赞
作者回复: 谢谢。
2021-07-14 
lyonger整体排查思路： 查看系统整体负载情况 -> 缩小问题的请求链路和排查范围 -> 采用ebpf给请求链路上的内核关键函数加上时间戳，分析时间差较长的环节，定位到cpu si高 -> perf针对高cpu使用率进行热点函数分析，找出调用次数最频繁的函数 -> 是调用次数频繁导致 or 本身执行一次该热点函数执行时间长导致？ -> 使用ftrace分析热点参数在每个CPU上的执行时间 -> 根据内核源码，分析该热点函数的执行逻辑 -> 操作系统原理 -> 破案。2021-09-184
yell采样10秒，怎么抓到0.01概率的超时的。2023-07-28归属地：浙江- Geek_9234b0给跪了2021-10-23
- 从远方过来老师，分享下下分析脚本吧2021-06-30
