JVM探秘:线上CPU占用过高故障排查

线上系统突然变得卡顿或无法访问,排除网络异常的情况下,检查服务器资源占用情况,如果CPU、内存、磁盘IO等资源占用过高,就会导致无法继续处理HTTP请求。

如果是CPU占用飙高,有可能是程序中存在死循环、死锁导致的,也有可能是内存紧张从而频繁GC导致的,要具体问题具体分析。

排查过程

这里记录一次线上CPU占用过高的故障排查过程,重点会用到jstack命令。

top命令

首先,使用top命令查看服务器资源使用情况,找到CPU占用过高的进程。

发现pid为29167的Java进程CPU占用很高,已经100%了。

ps -mp pid -o THREAD,tid,time

再通过ps命令查看这个进程的线程信息,tid为线程ID,time代表这个线程的已运行时间,通过上面的top命令,已经知道进程pid为29167,所以:

ps -mp 29167 -o THREAD,tid,time

可以看到,线程tid为29168的线程占用CPU很高,已经占用4分钟。

进制转换

29168转换成十六进制,因为jstack输出的线程id是十六进制形式,可以使用printf "%x\n" tid输出线程id的十六进制。

printf "%x\n" 29168

记录下29168的十六进制是71f0

jstack查看线程状态

使用JDK自带的jstack命令,指定pid后,可以查看Java进程中各个线程的运行状态,以及每个线程的跟踪堆栈。

可以把jstack结果输出到文件,然后在文件中查找,但一般为了快速定位问题,可以直接使用grep命令根据线程id查找。

使用管道操作及grep命令,输出30行结果:

jstack 29167 | grep 71f0 -A 30

根据输出结果,线程是RUNNABLE状态,可以在跟踪堆栈中定位到异常代码。

代码分析

根据jstack的线程跟踪堆栈,定位到异常代码,下面是代码内容。

WorkDayUtil:

package com.cellei.demo;

import java.util.Calendar;

public class WorkDayUtil {

    /*查询指定月份的工作日天数,格式:yyyy-MM,例如 2018-02 */
    public static int getWorkDay(String input){
        int count = 0;
        int month = Integer.parseInt(input.substring(5, 7));
        Calendar cal = Calendar.getInstance();
        cal.set(Calendar.YEAR, Integer.parseInt(input.substring(0, 4)));
        cal.set(Calendar.MONTH,  month - 1);
        cal.set(Calendar.DATE, 1);

        while(cal.get(Calendar.MONTH) < month){
            int day = cal.get(Calendar.DAY_OF_WEEK);
            if(!(day == Calendar.SUNDAY || day == Calendar.SATURDAY)){
                count++;
            }
            cal.add(Calendar.DATE, 1);
        }
        return count;
    }
}

Application:

import com.cellei.demo.WorkDayUtil;

public class Application {

    public static void main(String[] args) {
        int count = WorkDayUtil.getWorkDay("2018-12");
    }

}

问题出现在WorkDayUtil中的while循环条件,当传入的input参数不是12月份时,循环可以正常跳出,但当input是12月份时,比如这里的“2018-12”,这里就变成了死循环,while循环条件改成这样就正常了:

while(cal.get(Calendar.MONTH) + 1 == month){

其他情况

除了死循环会导致CPU占用过高,多线程编程时,死锁也会导致同样的问题。

还有一种情况,根据jstack跟踪线程堆栈,如果跟踪到的是GC线程,有可能是GC太过频繁导致的CPU飙高,这时需要分析内存占用情况,结合jstat和jmap命令,分析堆转储快照heapdump文件,得出最终结论。

线上故障多种多样,理解排查思路,剩下的就是经验的积累。

原文地址:https://www.cnblogs.com/cellei/p/12267729.html

时间: 2024-11-05 15:52:25

JVM探秘:线上CPU占用过高故障排查的相关文章

一次java Cpu占用过高的排查

某一个项目CPU占用率一直很高,经常在40%-50%之间,最近比较闲,就开始了挂查工作. 1.通过 jstack命令输出进程的堆栈信息 jstack 2788 >C:\log.txt 将堆栈信息输出到log.txt "dubbo-remoting-client-heartbeat-thread-1" #46 daemon prio=5 os_prio=0 tid=0x000000005c53e000 nid=0x240c waiting on condition [0x00000

Java CPU占用过高问题排查,windows和Linux

LINUX系统: linux系统比较简单: 1.使用命令 ps -ef | grep 找出异常java进程的pid.  找出pid为 20189 2. top -H -p 20189,所有该进程的线程都列出来了.看看哪个线程pid占用最多,然后将这个pid转换为16进制,我这里是22718转换完58be,注意要小写 3. jstack 20189 > jstack.log 将java进程信息导出到文件,在jstack.log文件中搜索 58be 类似于下图,可以通过线程名或包名之类的判断是那个线

Hession反序列化导致CPU占用飙高

背景 今天发布一个线上服务,暂且称之为O,发布完后,依赖O服务的2个服务C和W大量Time报警,并且这两个服务的CPU占用都飙到了40%左右,平时只有10%的样子. 这时去看O服务的监控,Time并没有升高,QPS反倒降了一半.同时C和W服务器日志中出现了大量的WARNING,信息如下: java.lang.ClassNotFoundException: com.我是不可描述的信息.PropertyAo Dec 02, 2016 6:24:33 PM com.alibaba.com.caucho

工具运行过程中,CPU占用过高的分析定位

之前使用Java Swing开发了一款设备档案收集工具.支持多台设备同时收集,每个设备使用一个线程.在同时收集多台设备信息时,发现CPU占用率居然达到了97%,而且高居不下.显然这样的性能是令人无法忍受的. 我们知道,通过jdk自带的工具jvisualvm可以查看每个线程的执行情况,但就是无法分析每个线程的CPU占用情况.由于工具是运行在Windows系统上的,所以也没办法像Linux下面那样通过命令去分析线程的CPU占用.而微软的process explorer工具可以解决这一难题.通过这个强

性能测试问题-Mysql数据库服务器的CPU占用很高

MySQl服务器CPU占用很高 1.  问题描述 一个简单的接口,根据传入的号段查询号码归属地,运行性能测试脚本,20个并发mysql的CPU就很高,监控发现只有一个select语句,且表建立了索引 2.  问题原因 查询语句索引没有命中导致 开始时的select SELECT `province_name`, `city_name` FROM `phoneno_section` WHERE SUBSTRING(?, phoneno_section_len) = phoneno_section

sqlserver 索引优化 CPU占用过高 执行分析 服务器检查

原文:sqlserver 索引优化 CPU占用过高 执行分析 服务器检查 1. 管理公司一台服务器,上面放的东西挺多的.有一天有个哥们告诉我现在程序卡的厉害.我给他说,是时候读点优化的书了.别一天到晚没个正形,现在写的程序卡的跑不动.他说我本地 是好好的,跑的很快.我说别扯那么多没用的,服务器不比你的本子强得多.待洒家上去看看.不看不知道一看吓一跳,CPU占用在95上下.开个程序是不卡,可整点有些时间是卡的一匹.这就令人很难受了. 本来服务器上也没有什么,就一个网站和几个数据库.那一个个分析吧,

从 kswapd0 进程CPU占用过高 到计算机内存详解

问题发现 操作系统都用分页机制来管理物理内存,操作系统将磁盘的一部分划出来作为虚拟内存,由于内存的速度要比磁盘快得多,所以操作系统要按照某种换页机制将不需要的页面换到磁盘中,将需要的页面调到内存中,由于内存持续不足,这个换页动作持续进行,kswapd0是虚拟内存管理中负责换页的,当服务器内存不足的时候kswapd0会执行换页操作,这个换页操作是十分消耗主机CPU资源的.如果通过top发现该进程持续处于非睡眠状态,且运行时间较长,可以初步判定系统在持续的进行换页操作,可以将问题转向内存不足的原因来

“RESOURCE MONITOR“CPU占用特别高

背景: SQL Server 2008 R2 10.50.1600 没有设置页面文件,内存为64G,数据库分配50G cpu使用占了50%以上,平时只有10-20%,某台服务器“RESOURCE MONITOR“CPU占用特别高. 原因: 网上有说是虚拟内存不够,也有说升级版本就可以解决. 猜测,是因此资源不足,导致RESOURCE MONITOR一直在运行,从而导致cpu太高 解决方法: 设置更大到内存

在VMware Workstation Pro 虚拟系统中CPU占用过高的原因?

分析原因: 在超线程单处理器主机上,采用虚拟 SMP 的虚拟机可能无法达到正常性能水平.即便在多处理器主机上,如果您运行了多个工作负载,导致整体 CPU 资源需求超过物理资源极限,虚拟机的性能也会受到影响. 在配置虚拟机处理器的时候建议根据物理主机配置仅设置处理器数量.每个处理器核心数量即可,如果勾选禁用二进制转换加速.虚拟化 Intel VT-x/EPT 或 AMD-V/RVI或虚拟化 CPU 性能计数器,将造成虚拟系统CPU占用过高.