Brendan Gregg: 一个实战派大神

小咪咪 2022-10-05 08:54 114阅读 0赞

第一次知道Brendan Gregg，是我还在Juniper的时候。插点花絮，关于Juniper，你可以百度下“程序员薪水最高的25家公司”，那就是因为这条新闻才打定了主意去的Juniper, 只能说，Juniper的HR们很优秀。 言归正传，我那会在Juniper主要是研究网络性能优化的一些东西，Juniper的系统是BSD，所以我就研究上了Dtrace，而Dtrace Toolkit以及Dtrace书的的作者就是Brendan Gregg。 不过我并没有因此而跟Brendan Gregg正面刚，我刚的是Oleksandr Tymoshenko，Dtrace on MIPS的作者，因为在MIPS上Dtrace的fbt/pid这两个特性没有实现，所以我就给Oleksandr Tymoshenko发了封邮件请教这个问题。Oleksandr Tymoshenko很热情，很快的回复了我"The problem with fbt on MIPS is that there is no clear way to determine function boundaries", 就是MIPS代码的编译很随意，函数与函数之间没有一个清晰的边界。 举个例子，x86上的一个function，它的汇编代码一般是这样的： begin with: push %ebp mov %esp,%ebp <function body> end with: ret 它有很清晰的指令来区分函数的开始与结束。 而在MIPS上就没有很严格的指令来做区分，毕竟MIPS是RISC，指令比X86是少的可怜。 以这个故事开头，主要是想给大家一个直观感受，给Dtrace做出重要贡献的Brendan Gregg，他在计算机体系结构方面的知识是多么的强大。 对于Brendan Gregg这个名字你可能会感觉陌生，不过对于下面这个图，相信你一定不会陌生：

![format_png][]

performance tools

这个图就是出自Brendan Gregg之手。 对于Brendan Gregg的事迹我就不在赘述，感兴趣的可以直接去看他的博客，相信你一定会获益良多。 ( [博客1][1] [博客2][2] ) 关于他的个人博客，我再说一件事。 我们的服务器上曾经出现过很随机的TCP重传问题，就是那种不知道什么时候会出现什么时候又自动恢复的问题，这种问题往往令人很头疼，因为它是随机出现的而且每次的时间也都短暂，等你反应过来要上去抓取现场信息了它可能就已经消失了。 对于TCP重传问题，显然是需要抓包分析，常用的抓包分析工具在Linux上就是tcpdump了。tcpdump是个非常重的抓包工具，它会抓取进出interface的所有包，显然这对系统的性能会有很大的影响。所以我们用tcpdump来抓包，一般都是在问题出现时上去抓取，抓取一段时间后再停掉它。所以tcpdump对于这种随机出现并且持续时间短的tcp重传问题就爱莫能助了，你不能够一直让它在那里运行着抓包，这对系统影响太大了。 于是Brendan Gregg就开发出了一个轻量级的tcp重传抓取工具: tcpretrans。这个工具它只抓取所有重传的包，具体的原理是借助Linux Kernel的ftrace机制在tcp\_retransmit\_skb这个函数加了一个hook来获取重传包的skb地址，然后以这个skb的地址作为hash key去/proc/net/tcp这个文件里面匹配tcp连接信息，然后把发生重传的这个tcp连接的信息(time,src,sport,dst,dport,state)给打印出来。由于它只抓取该服务器发出的重传包，所以它的系统开销是很小的，我们完全可以把它部署到服务器上一直运行着去抓包。 这个工具也确实有效的帮助我们分析清楚了不少TCP重传的问题。 不过可惜，这个工具有个缺点，对于持续时间不足1s的TCP连接，它是抓取不到tcp连接五元组信息的，所以我给它改写了下，增加了一个选项，利用ftrace的trace\_pipe来实时的统计所有重传包，不过显然这样子对系统性能是有一些影响的，不适合一直运行着。 Brendan Gregg的很多博客我都是看了很多遍，它对我对系统的理解确实帮助很大，所以为了从物质上来回报这个大哥，我就花了351¥去amazon上买了他的《systems performance》这本书。 这本书可以称得上是一个系统分析大全，他整理了各种分析工具，cpu／内存/磁盘／网络／文件系统等各方面的，所以它其实也可以作为一个参考书，当你遇到很棘手的问题时翻一翻它没准就能豁然开朗。 不过这本书并不仅仅是个工具大全，工具介绍只是占了这本书的很小一部分，它最主要的是对系统分析方法论的归纳总结以及技术层面的解释，以及对于一些计算机的基本概念，比如延时，响应时间，利用率，吞吐量等做了非常彻底的解释，就是给你说明白为什么会是这样子，为什么会有这个概念出来，以及怎么样去分析这些个概念。 不过，话说回来，如果你能看懂他的博文，而且也不打算像我一样回报这个大神什么，你就没有必要买这本书了。他的博文就是这本书的一个浓缩，或者说精华吧。 这本书还被翻译成了中文版，不过我不建议大家看中文翻译版，我现在已经不再看各种翻译书了，计算机的东西需要看翻译版么？！ 而且这本书的英文确实也很好懂。

关于我跟Brendan之间的交集，还有一件事。 我在2017年给Linux内核贡献了一个增强tcp\_set\_state这个tracepoint的patchset（见[net: tracepoint: replace tcp\_set\_state tracepoint with inet\_sock\_set\_state tracepoint][net_ tracepoint_ replace tcp_set_state tracepoint with inet_sock_set_state tracepoint]），然后Brendan看到这个改动后，发邮件给我和networking的掌门人David Miller问这个patchset是否会出现在4.15的内核上，我答复他说不会出现在4.15上会出现在4.16上。后来Brendan把我的这个patchset写在了他的一篇blog里：[TCP Tracepoints][] 可见Brendan一直在密切关注Linux社区的技术动态，尤其是涉及到问题分析以及性能优化手段的技术动态。所以关注Brendan你也可以了解到Linux社区一些有价值的最新技术动态。

[format_png]: /images/20221005/e6cf832b5bdf403782e7e7f0d3952f7d.png
[1]: http://www.brendangregg.com/
[2]: http://dtrace.org/blogs/brendan/
[net_ tracepoint_ replace tcp_set_state tracepoint with inet_sock_set_state tracepoint]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.3-rc1&id=563e0bb0dc74b3ca888e24f8c08f0239fe4016b0
[TCP Tracepoints]: http://www.brendangregg.com/blog/2018-03-22/tcp-tracepoints.html