【JVM性能优化】问题故障排查的解决方案(上)
前提概要
线上故障主要会包括cpu、磁盘、内存以及网络问题,而大多数故障可能会包含不止一个层面的问题,所以进行排查时候尽量四个方面依次排查一遍。同时例如jstack、jmap等工具也是不囿于一个方面的问题的,基本上出问题就是df、free、top三连,然后依次jstack、jmap伺候,具体问题具体分析即可。
CPU的问题
一般来讲我们首先会排查cpu方面的问题。cpu异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁gc以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)导致的,可以使用jstack来分析对应的堆栈情况。
jstack分析cpu问题
- 先用ps命令找到对应进程的pid(如果你有好几个目标进程,可以先用top看一下哪个占用比较高),来找到cpu使用率比较高的一些线程
top -H -p pid
这里需要注意的是 -p代表着通过进程号,-H 查询的是输出使用率最高线程
- 将占用最高的pid转换为16进制得到nid
printf ‘%x\n’ pid
- 接着直接在jstack中找到相应的堆栈信息
jstack ‘0x42’ | grep ‘nid’ -C5 –color
可以看到我们已经找到了nid为0x42的堆栈信息,接着只要仔细分析一番即可。
- 排查整个jstack文件
- 当然更常见的是我们对整个jstack文件进行分析,通常我们会比较关注WAITING和TIMED_WAITING的部分,BLOCKED就不用说了。
- 使用命令
cat jstack.log | grep "java.lang.Thread.State" | sort -nr | uniq -c
来对jstack的状态有一个整体的把握,如果WAITING之类的特别多,那么多半是有问题啦。
JVM频繁gc(FullGC)
使用jstack来分析问题,但有时候我们可以先确定下gc是不是太频繁,使用jstat -gc pid 1000
命令来对gc分代变化情况进行观察,1000表示采样间隔(ms)。
- S0C/S1C、S0U/S1U、EC/EU、OC/OU、MC/MU分别代表两个Survivor区、Eden区、老年代、元数据区的容量和使用量。
- YGC/YGT、FGC/FGCT、GCT则代表YoungGc、FullGc的耗时和次数以及总耗时。<