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

刚入行那会，看到有人在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
        如果直接用 strace 跟踪某个进程的话，满屏翻滚的字符，如信息炸弹般混淆你的视线，到最后很难发现问题，我们先加 -c 参数统计一下：ltrace -cp

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

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

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

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

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