closer2021-01-29看了老师的文章涨见识了。深深的知道了自己的不足了，请问一下老师，作为一个运维工程师，怎么学习这种底层的内核开发细节？谢谢老师指导作者回复: @closer, 可以从Linux内核源代码的编译安装开始，然后读一本Linux内核书籍。
共 3 条评论9
我来也2021-02-06大集群就容易遇到IPVS规则过多的问题吧。 有点好奇 1. 集群中的其他节点应该也会存在类似的问题吧。 2.每次都是固定在这一个核上做这个事情么？作者回复: @我来也 > 集群中的其他节点应该也会存在类似的问题吧。 是的，在kubernetes cluster里，每个节点都会有同样的问题。ipvs rules是为每个service的in cluster vip设置的，在所有节点上的配置都是一样的。 > 每次都是固定在这一个核上做这个事情么？ 是的，对于timer函数，在哪个cpu核上注册，后面就一直在那个核上执行了。
共 2 条评论8
莫名2021-01-29很赞的排查思路。 softirq 通常是节点内网络延迟的重要线索。不借助 eBPF 工具时，可以先采用传统工具 top、mpstat 重点观测下 softirq CPU 使用率是否存在波动或者持续走高的情况。如果存在，进一步使用 perf 进行热点函数分析。 不过使用现有的 eBPF softirq 相关工具更方便。作者回复: @莫名， 这里的问题就是一开始如何就认为是softirq这里出问题。在节点有80核的情况下，简单看一下top里的si， 它的usage是不多的。
共 2 条评论5
Joe Black2021-02-04“把 IPVS 规则的状态统计从 TIMER softirq 中转移到 kernel thread 中处理”，这个事情是通过什么配置就可以实现的吗？总不能改内核模块吧？作者回复: 不能通过配置来实现，需要改内核。
4
那时刻
2021-01-29请问老师，IPVS过多是由于service导致的么？还是旧service遗留导致的呢？ 另外，不知可否分享下您实现的ebpf工具呢？作者回复: @那时刻， 对的IPVS是由于cluster中有大量的service, 不是残留。 我们的ebpf工具和这个有些类似吧。 https://github.com/yadutaf/tracepkt 我们增加了更多的tracepoint点和kprobe点，多了一些event的信息
4- Geek_c925842021-07-14干货满满，赞
作者回复: 谢谢。
lyonger2021-09-18整体排查思路： 查看系统整体负载情况 -> 缩小问题的请求链路和排查范围 -> 采用ebpf给请求链路上的内核关键函数加上时间戳，分析时间差较长的环节，定位到cpu si高 -> perf针对高cpu使用率进行热点函数分析，找出调用次数最频繁的函数 -> 是调用次数频繁导致 or 本身执行一次该热点函数执行时间长导致？ -> 使用ftrace分析热点参数在每个CPU上的执行时间 -> 根据内核源码，分析该热点函数的执行逻辑 -> 操作系统原理 -> 破案。4
Geek_d6bf272023-07-28 来自浙江采样10秒，怎么抓到0.01概率的超时的。- Geek_9234b02021-10-23给跪了
- 从远方过来2021-06-30老师，分享下下分析脚本吧