通常状况下,性能报告中只说CPU使用率高的时候,并不能帮忙定位
问题。因为CPU高会有多种不同的状况。CPU有五种状态(us sy id wa st), 在vmstat中能显示进去,这个想必很多人都分明。在代码耗费CPU的时候(这也是通常性能剖析中会遇到的),是US状态的CPU。当然还存在一种状况,就是代码产生的零碎调用特地高,这种状况下SY的CPU也会高(这种状况比拟少见,在我的职业生涯中只见过一次)。对于JAVA语言来说,咱们不须要特地简单的profile工具就能够做到定位到代码。
在写具体的分析方法之前,须要说一下线程的状态转换关系,咱们先来看一下零碎级的线程状态转换关系。
通过这个转换关系,能够看到,在线程产生之后,会先到ready的状态。在这个状态上是在期待CPU的。而在runing状态才是真正在CPU上执行的。请留神这个区别。
而vmstat显示的 r 列是包含了ready和running的线程(会因操作系统的不同有区别,然而对大部分linux零碎都是这样)。请留神这一点,因为网上有很多在写vmstat的解释的时候,说 r 列是示意正在运行的过程数或者说 r 是示意正在运行的线程数,这一点是不对的。给大家看一个例子(这也是上面要说到的例子):
这是我的一个云服务器上正在运行的top。能够看到以后tasks(过程)中只有一个是running的状态的。而这时的vmstat呢?
这个服务器只有两个CPU,所以如果r是说正在运行的过程或线程数的话必定是不正确的,因为两个CPU同时运行的最多是两个线程。
所以请记住,这个 r 值就包含了期待CPU的线程(也就是ready状态的)和正在运行的线程(也就是running状态的)。
当前有工夫再解释其余零碎级的线程状态,可能有些人感觉其余状态也没什么好解释的,然而在性能剖析中,线程的状态和一些性能计数器是有关联关系的,比如说suspended状态是CPU工夫片用完导致临时被换出;而blocked是因为要期待某个条件被满足而阻塞;并且这两种状态都有可能导致CPU使用率高。在剖析的过程中,这些信息给咱们的是一个方向。所以后面说到仅说CPU高不能帮忙剖析问题,因为CPU高有多种起因。
因为上面要说的是JAVA,所以来看一下JAVA的线程状态转换关系。
从这个图中,咱们能够看到JAVA的过程有多种状态(具体状态的解释请自行搜寻),怎么看到这些状态都在干什么,就须要把栈打出来看。在栈中,能够看到具体对应的代码(对其余编译语言来说,要看看到正在运行的code也是要看栈的)。另外,在性能剖析中,栈的剖析是十分重要的一块内容,明天因为只是为了阐明从CPU高怎么定位到代码层,所以不过多解释线程的状态了,当前有工夫再写文章阐明。
实例:
上面来操作一下,首先执行一个耗费CPU的JAVA实例(实例是7D Group成员所编,有趣味入手操作的能够到网上轻易找一个小例子或本人编写一个)。查看vmstat的状态。
从上图能够看到右边窗口在执行一个耗费CPU的Demo,而左边的窗口看到以后零碎的CPU曾经齐全被消耗掉了。过程号通过top命令就能够晓得:
上面就要看一下这个过程中的哪些线程耗费了CPU。
通过pidstat能够看到(不好意思的是,pidstat的截图被我笼罩掉了,又不想从新开始所以就不截图啦),有10个线程耗费着CPU资源。我把命令放在这里,有趣味的能够本人操作。
pidstat -p 10846 -u -d -t -w -h 1 1000
从上命令能够看到,有多个线程耗费着CPU。线程ID是:10861、10862、10863等等。
用jstack做一下thread dump。
[root@7dgroup ~]# jstack -l 10846 > 10846.threaddump
再关上这个生成的文件。
nid是指native ID,对应着零碎级的tid。只不过TID显示的是10过程的,NID显示的是16进制的。
咱们转换一个线程号来查找。
[root@7dgroup ~]# printf %x’\n’ 10861
2a6d
再对应到threaddump文件中。
图片
显然能够去查这个CPUTestThreadDemo.java的第13行了。
从这个例子能够看出,对java的代码耗费CPU高的剖析只须要通过零碎级的命令和JDK自带的命令就能够实现了。因为这个例子非常简单,步骤比较清楚。但在理论剖析代码泛滥,逻辑简单的利用,有可能你看到的是CPU在线程上的耗费是在不停的切换的,所以就须要多做些thread dump,一个个剖析。当然借助些工具剖析,通常能够让咱们在剖析简单的利用时事倍功半。
这里只阐明一个思路。
对JAVA的剖析来说,曾经有十分多的人写了十分多的文章了,我之所以写这个文章,是为了让文章能更系列一些。