谁偷走了你的服务器性能——Strace & Ltrace篇

张文杰
11963     

刚入行那会,看到有人在Linux下面用strace,看到满屏翻滚的屏幕打印,除了崇拜还是崇拜,现在如果你遇到性能问题求助别人,十有八九会建议你用 strace 挂上去看看,但是看到的依然是翻滚的屏幕,却十有八九看不出个所以然。作者希望通过一个实例,科普一下Strace & ltrace 诊断问题的简单思路。

当我们登录一台高负载服务器后,先TOP一下:

秘籍:在运行 top 时,按「1」查看多核CPU 列表「shift+p」以 CPU使用情况从高到低排队。

不难发现 CPU 主要被其中某一进程占用,PID:9108,并占用大量内存,但是SWAP 也不严重,内存不是主要原因。

从CPU 列表中能看到 CPU 主要消耗在用户态「us」,而不是内核态「us」,和我的经验预判基本一致。

Linux 操作系统有很多用来跟踪程序行为的工具,内核态的函数调用跟踪用「strace」,用户态的函数调用跟踪用「ltrace」,所以这里我们应该用「ltrace」

        ltrace -p <PID>
        如果直接用 strace 跟踪某个进程的话,满屏翻滚的字符,如信息炸弹般混淆你的视线,到最后很难发现问题,我们先加 -c 参数统计一下:ltrace -cp <PID>

然后你就可以把问题反馈给开发相关函数调用的同学来排查,那么这就是我们从系统层面能排查出来的全部了吗????
显然不是!
我们还可以使用TOP命令进一步跟踪到线程信息,可以单独对每个线程进行跟踪
        top -p  <PID> -H

另外虽然CPU主要消耗在用户态,但是内核态的调用对程序调优的帮助也是很大的,我们这里也用Strace 对进行跟踪一下
      strace -cp <PID>

很明显的看到 CPU 主要被 nanosleep 操作消耗了,还可以通过 -e 参数单独跟踪一下 nanosleep 并加 -T参数 记录一下耗时:
      stract -p <PID> -e nanosleep  -T

很明显一个 nanosleep 操作需要消耗1s,至于nanosleep 干什么的,你可以请教全能的 man"man nanosleep" 看看。后面的事情就要去查看业务代码了!      

点到为止,欢迎吐槽切磋,本帖只做案例分析思路,深入的用法可以请教万能的 Google或全能的man。


版权所有 侵权必究

如需转载请联系

0571-26691657

未经授权禁止转载,详情见转载须知

联系我们

恒 生 技 术 之 眼