Brendan Gregg: 一个实战派大神

laoar
2016-05-14 看过

第一次知道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这个名字你可能会感觉陌生,不过对于下面这个图,相信你一定不会陌生:

performance tools

这个图就是出自Brendan Gregg之手。 对于Brendan Gregg的事迹我就不在赘述,感兴趣的可以直接去看他的博客,相信你一定会获益良多。 ( 博客1 博客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),然后Brendan看到这个改动后,发邮件给我和networking的掌门人David Miller问这个patchset是否会出现在4.15的内核上,我答复他说不会出现在4.15上会出现在4.16上。后来Brendan把我的这个patchset写在了他的一篇blog里:TCP Tracepoints 可见Brendan一直在密切关注Linux社区的技术动态,尤其是涉及到问题分析以及性能优化手段的技术动态。所以关注Brendan你也可以了解到Linux社区一些有价值的最新技术动态。

60 有用
2 没用

查看更多豆瓣高分好书

评论 14条

查看全部14条回复·打开App

推荐Systems Performance的豆列

了解更多图书信息

豆瓣
免费下载 iOS / Android 版客户端