Java进程CPU高负载排查步骤_java进程cpu使用率高排查_YouluBank的博客-CSDN博客
【问题定位】使用arthas定位CPU高的问题_arthas cpu高_秋装什么的博客-CSDN博客
CPU飙升可能原因
- CPU 上下文切换过多。
- 对于 CPU 来说，同一时刻下每个 CPU 核心只能运行-个线程，如果有多个线程要执行，CPU 只能通过上下文切换的方式来执行不同的线程。
- 上下文切换需要做两个事情：保存运行线程的执行状态；让处于等待中的线程执行
- 这两个过程需要 CPU 执行内核相关指令实现状态保存，如果较多的上下文切换会占据大量 CPU 资源，从而使得 cpu 无法去执行用户进程中的指令，导致响应速度下降。
- 在 Java 中，文件1O、网络 1O、锁等待、线程阻塞等操作都会造成线程阻塞从而触发上下文切换
- CPU 资源过度消耗，也就是在程序中创建了大量的线程，或者有线程一直占用CPU 资源无法被释放，比如死循环!
- CPU 利用率过高之后，导致应用中的线程无法获得 CPU 的调度，从而影响程序的执行效率!
使用命令查找
采用top命令定位进程
登录服务器，执行top命令，查看CPU占用情况，找到进程的pid
很容易发现，PID为29706的java进程的CPU飙升到700%多，且一直降不下来，很显然出现了问题。
使用top -Hp命令定位线程
使用 top -Hp 命令（为Java进程的id号）查看该Java进程内所有线程的资源占用情况
top -Hp 29706
很容易发现，多个线程的CPU占用达到了90%多。我们挑选线程号为30309的线程继续分析。
使用jstack命令定位代码
线程号转换为16进制
printf “%x\n” 命令（tid指线程的id号）将以上10进制的线程号转换为16进制：
printf "%x\n" 30309
转换后的结果分别为7665，由于导出的线程快照中线程的nid是16进制的，而16进制以0x开头，所以对应的16进制的线程号nid为0x7665
采用jstack命令导出线程快照
通过使用dk自带命令jstack获取该java进程的线程快照并输入到文件中： jstack -l > ./jstack_result.txt 命令（为Java进程的id号）来获取线程快照结果并输入到指定文件。
jstack -l 29706 > ./jstack_result.txt
根据线程号定位具体代码
在jstack_result.txt 文件中根据线程好nid搜索对应的线程描述
cat jstack_result.txt |grep -A 100 7665
根据搜索结果，判断应该是ImageConverter.run()方法中的代码出现问题
也可以直接采用jstack |grep -A 200 来定位具体代码
jstack 29706 |grep -A 200 7665
"System Clock" #28 daemon prio=5 os_prio=0 tid=0x00007efc19e8e800 nid=0xae24 waiting on condition [0x00007efbe0d91000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at java.lang.Thread.sleep(Thread.java:340)
at java.util.concurrentC.TimeUnit.sleep(TimeUnit.java:386)
at com.*.order.Controller.OrderController.detail(OrderController.java:37) //业务代码阻塞点
使用工具查找
使用arthas
下载arthas
curl -O https://arthas.aliyun.com/arthas-boot.jar
1
启动arthas
java -jar arthas-boot.jar
选择3，进行监听我们的应用程序。
模拟CPU高的场景
@GetMapping("/cpu")
public void cpu() {
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(2, 5, 1000, TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(100));
threadPoolExecutor.execute(new Runnable() {
public void run() {
while (true) {
log.info(System.currentTimeMillis() + "");
}
}
});
}
dashboard
thread -n {number}
按照CPU使用率排序，并展示前n个线程
thread [pid]
展示指定线程的线程栈
模拟查看方法调用耗时
@RestController
@Slf4j
public class TestController {
@RequestMapping("/trace")
public String trace(int number) throws InterruptedException {
number++;
fun1(number);
return "Hello World!";
}
private void fun1(int number) throws InterruptedException {
TimeUnit.MILLISECONDS.sleep(10);
number++;
fun2(number);
}
private void fun2(int number) throws InterruptedException {
TimeUnit.MILLISECONDS.sleep(300);
number++;
fun3(number);
}
private void fun3(int number) throws InterruptedException {
TimeUnit.MILLISECONDS.sleep(20);
}
}
trace
trace com.charles.web.TestController trace，监听TestController的trace方法。
访问wget http://localhost:7077/trace?number=1，可以看出trace和fun1方法的耗时。
trace命令只会匹配当前的方法，以及下一级方法。
trace -E com.charles.web.TestController trace|fun1|fun2|fun3
可以看出fun2方法耗时比较长。
watch
watch com.charles.web.TestController fun2 “{params,returnObj}” -x 2 -b，watch方法可以观察到入参，此时入参是3。
其它情况
从gc角度出发，是否存在大量gc，首先确定当前内存消耗情况，使用top命令或者查看设备监控管理系统，确定内存利用率达97%：
总结
CPU飙升问题定位的一般步骤是：
1.首先通过top指令查看当前占用CPU较高的进程PID；
2.查看当前进程消耗资源的线程PID： top -Hp PID
3.通过print命令将线程PID转为16进制，根据该16进制值去打印的堆栈日志内查询，查看该线程所驻留的方法位置。
4.通过jstack命令，查看栈信息，定位到线程对应的具体代码。
5.分析代码解决问题。
