一个应用占用CPU很高,除了确实是计算密集型应用之外,通常原因都是出现了死循环。
下面我们将一步步定位问题,详尽的介绍每一步骤的相关知识。
一、通过top命令定位占用cpu高的进程
执行top命令得到以下结果:top命令执行结果
通过上图可以明显看出进程PID41843占用cpu过高,明显存在问题,定位到了进程id。当然如果你想只观察进程PID41843的CPU和内存以及负载情况,可以使用以下命令
top -p 41843。
结果如下:top -p 41843命令执行结果
这里顺便解释下上图各个参数的意义,有利于读者更好的排查问题。
任务队列信息 | 含义 |
---|---|
14:06:34 | 当前时间 |
537 days | 系统运行时间 |
6 min | 用户在线时间 |
6 users | 在线用户数 |
load average: 0.41, 0.45, 0.43 | 系统负载,即任务队列的平均长度。1分钟前、5分钟前、15分钟前平均负载 |
2)第二行为进程的信息
进程信息 | 含义 |
---|---|
Tasks: 1 total | 进程总数 |
0 running | 正在运行的进程数 |
1 sleeping | 睡眠的进程数 |
0 stopped | 停止的进程数 |
0 zombie | 僵尸进程数 |
cpu信息 | 含义 |
---|---|
6.1% us | 用户空间占用CPU百分比 |
1.5% sy | 内核空间占用CPU百分比 |
0.0% ni | 用户进程空间内改变过优先级的进程占用CPU百分比 |
92.2% id | 空闲CPU百分比 |
0.0% wa | 等待输入输出的CPU时间百分比 |
0.0% hi | 硬件中断 |
0.0% si | 软件中断 |
0.0%st | 实时 |
物理内存信息 | 含义 |
---|---|
Mem: 191272k total | 物理内存总量 |
173656k used | 使用的物理内存总量 |
17616k free | 空闲内存总量 |
22052k buffers | 用作内核缓存的内存量 |
交换区信息 | 含义 |
---|---|
Swap: 192772k total | 交换区总量 |
0k used | 使用的交换区总量 |
192772k free | 空闲交换区总量 |
123988k cached | 缓冲的交换区总量 |
二、通过top命令定位问题进程中每个线程占用cpu情况
通过问题进程中每个线程占用cpu情况使用可以使用如下命令:
top -p 41843 -H
查看进程PID41843的每一个线程占用CPU情况,如图。top -p 41843 -H的执行结果
由上图明显可以发现,线程PID41892CPU占用率最高,接下来定位该线程的代码是否出现异常导致cpu占用过高。
三、通过jstack 命令定位问题代码
上一步发现PID41892占用的CPU过高,就将这个PID转换成16进制,易知,PID41892转化成16进制为a3a4。使用如下命令命令定位问题代码:
jstack 41892 | grep a3a4
输出如下:
"Thread" prio=10 tid=0x00007f950043e000 nid=0x54ee in test();
可以分析得到: 线程Thread下的wait()函数cpu使用率很高,查看源代码中的test()函数代码如下:
public void test(){
while(true){
for(int i = 0 ;i<100;i++);
}
}
while循环无法结束,一直抢占cpu,导致程序cpu使用过高,修改代码即可。
到此为止,因为代码问题导致的cpu使用过高的故障排查方法就介绍完了。
一、异常出现的原因
1.Java.lang.OutOfMemoryError: PermGen space
PermGen space全称是Permanent Generation space,是指内存的永久保存区域, 这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中, 它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对 PermGen space进行清理,所以如果你的应用中有很多CLASS的话,就很可能出现PermGen space错误。如果你的WEB或者APP用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息。
解决方法:
1.调整PermSize、MaxPermSize的大小;
2.减少jar重复使用,重复占用内存。
2.java.lang.OutOfMemoryError: Java heap space
Heap size 设置 JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值,其初始空间(即-Xms)是物理内存的1/64,最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。
在JVM中,如果98%的时间是用于GC且可用的Heap size 不足2%的时候将抛出此异常信息。提示:Heap Size 最大不要超过可用物理内存的80%,一般的要将-Xms和-Xmx选项设置为相同,而-Xmn为1/4的-Xmx值。
二、异常原因排查步骤
1.通过jstat命令查询gc情况
通过top命令定位到内存占用过高的进程PID后,排查该进程的GC情况,
命令:jstat -gccause 41843 2000
jstat命令的结果
2.通过jmap命令查询进程实体类内存占用情况
如果步骤1中发现,gc非常频繁,则可以使用jmap命令查询进程实体类内存占用情况。
命令: jmap -histo:live 41843 | head -n 100
jmap 命令结果
如上图可以看出,jdbc所占用的存活对象特别多,而且占用的内存也很高,从这里就可以看出,需要去检查下mysql的调用中,哪里存在问题,有内存泄露。
3.通过jmap命令查询进程堆的使用情况
如果以上没有查出问题,可以看看进程中,新生代、老年代、永久代的使用情况。
命令: jmap -heap 41843
jmap -heap 41843结果
如上图,如果发现频繁的gc是因为新生代、老年代、永久代分配的大小有问题,则可以通过修改设置解决。
永久代解决方法(同上):
1.调整PermSize、MaxPermSize的大小;
2.减少jar重复使用,重复占用内存。
新生代、老年代解决方法:
1.调整Xms -Xmx -Xmn的大小
示例及参数注解:
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:PermSize=64M -XX:MaxPermSize=128M -XX:MaxTenuringThreshold=0
-Xmx3550m:设置JVM最大可用内存为3550M。
-Xms3550m:设置JVM促使内存为3550m。此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存;
-Xmn2g:设置年轻代大小为2G。整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8;
-Xss128k:设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右;
-XX:NewRatio=4:设置年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代)。设置为4,则年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5;
-XX:SurvivorRatio=4:设置年轻代中Eden区与Survivor区的大小比值。设置为4,则两个Survivor区与一个Eden区的比值为2:4,一个Survivor区占整个年轻代的1/6;
-XX:PermSize=64M JVM初始分配的非堆内存(永久代);
-XX:MaxPermSize=128M JVM最大允许分配的非堆内存,按需分配;
-XX:MaxTenuringThreshold=0:设置垃圾最大年龄。如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代。对于年老代比较多的应用,可以提高效率。如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概论。