一个load飙高的过程分析，非常有价值(转)

关于us高和sy高的问题分析：

当us值过高时，表示运行的应用消耗大量的CPU。java应用造成us高的原因主要是线程一直处于可运行（Runnable）状态，通常这些线程在执行无阻塞、循环、正则或纯粹的计算等任务造成的；另外一个可能也会造成us高的原因是频繁GC。

当sy值高时，表示linux花费了更多的时间在进行java线程切换。java应用造成这种现象的主要原因是启动的线程比较多，且这些线程多数处于不断的阻塞（例如锁等待，IO等待状态）和执行状态的变化过程中，这就导致了操作系统要不断地切换执行的线程，产生大量的线程上下文切换。

对于jstack做的ThreadDump的栈，可以反映如下信息。

如果某个相同的call stack经常出现， 我们有80%的以上的理由确定这个代码存在性能问题（读网络的部分除外）；

如果相同的call stack出现在同一个线程上（tid）上， 我们很很大理由相信， 这段代码可能存在较多的循环或者死循环；

如果某call stack经常出现， 并且里面带有lock，请检查一下这个lock的产生的原因， 可能是全局lock造成了性能问题；

在一个不大压力的群集里（w<2）， 我们是很少拿到带有业务代码的stack的， 并且一般在一个完整stack中， 最多只有1-2业务代码的stack，

如果经常出现， 一定要检查代码， 是否出现性能问题。

如果你怀疑有dead lock问题， 那么请把所有的lock id找出来，看看是不是出现重复的lock id。

http://blog.csdn.net/axman/article/details/7104819