一个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

上一篇:Faucets--区块链各个链水龙头


下一篇:C# 枚举、字符串、值的相互转换