Java CPU或内存使用率过高问题定位教程

已于 2024-01-05 13:44:38 修改
阅读量1.8k 收藏 27
点赞数 23
分类专栏： Java 文章标签： 性能优化 内存溢出 cpu过高 打印堆栈 OOM定位 Arthas jvisualVM
于 2024-01-04 14:17:26 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/x541211190/article/details/135066285
版权

简介

Spring cloud微服务广泛应用后，服务的监控和运维压力也与日俱增，经常有服务出现CPU或者内存使用率过高的告警，那么遇到这样的问题我们该如何排查呢？我们可以借助哪些工具来定位问题呢？本文将介绍一下遇到此类问题的解决思路和方法。

一.常见的性能问题优化的经验分享

1.通过应用日志定位思路

对于业务体量不大，QPS不高的服务来说，一般出现性能问题还是很好定位的，比如通过Prometheus等监控平台出现CPU或内存使用率过高的时间点，看一下这个时间点附近的应用日志，一般就可以看出其内存溢出的地方了，偶尔报错的地方也并非就是引发性能问题的地方，因为报错的地方只是压垮骆驼的最后一根稻草，在此报错点之前的地方有出现耗费性能的操作导致的。有时候监控趋势图显示CPU彪生，但其实是因为OOM引发的，要清晰的定位这些问题，这就得再借助下其他工具了，后文再介绍。

2.常见的性能问题

我们发现了日志报错点后，第一点就要去思考有没有往内存中加载大量数据的操作，比如Excel导出一次性加载大量数据而不采用分页的、一次加载大量Redis缓存的、一次Select查询大量Mysql数据的地方。

这些都是及其容易引发内存溢出的地方，也是很多刚工作的同学经常犯的错误，他们在开发环境数据量少时不会暴露此类问题，但是一旦发布生产环境，单表数据量到百万数量级，此类问题就会出现，所以自己或问问同事有没有写过类似的操作或接口，从而快速定位。

以上都是凭借经验判断，如果开发者资历尚浅或者问题隐藏较深，我们就需要借助一些工具来定位问题了。

二.CPU利用率过高问题定位

如果发现CPU利用率过高，比如达到了90%-100%时，我们可以直接登陆应用服务器，通过以下步骤定位问题：

1.查看占用CPU高的线程

命令：top

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND\
4380 root      20   0 9415956 2.350g  26772 S  90.3 41.4 426:14.30 java\
2083 root      20   0 1141656   9460   7044 S   0.7  0.2 130:19.20 Asiainfocwexam\
2038 root      20   0  495668   5880   4776 S   0.3  0.1 524:46.15 Asiainfocwmonit\
2093 root      20   0 1377548  10244   8324 S   0.3  0.2 514:56.84 Asiainfocwsvrd\
6708 root      20   0   27520   3236   2460 S   0.3  0.1   0:00.15 sshd\
21114 root      20   0  729064  18340   6856 S   0.3  0.3  39:46.81 bkmonitorbeat\
1 root      20   0   41284   2860   1940 S   0.0  0.0   0:15.97 systemd

我们可以看出第一个进程PID：4380的CPU占用率过高，他就是我们的java服务，这里PID指的是进程，我们需要根据进程号，找到其占用CPU的线程。

命令：top -Hp 4380

注：

  • 命令中H大写，p小写

  • top：在终端实时显示系统性能数据的命令。

  • -H：该选项用于显示所有线程的信息而不是仅显示总体的信息。

  • -p 4380：该选项指定要监视的进程的PID。在这里，4380是一个占位符，你可能会替换为实际的进程PID。

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    4558 root 20 0 9415956 2.333g 26772 S 92.9 41.1 160:56.84 java
    4389 root 20 0 9415956 2.333g 26772 S 0.7 41.1 11:17.82 VM Thread
    4473 root 20 0 9415956 2.333g 26772 S 0.7 41.1 4:38.15 redisson-netty-
    4480 root 20 0 9415956 2.333g 26772 S 0.7 41.1 3:19.37 redisson-netty-

我们可以看到PID:4558的线程CPU使用率较高。

打印出问题线程的堆栈信息

命令：printf '%x\n' 4558

将线程号转为16进制显示，用于在堆栈中定位线程。

注：

  • printf：是一个格式化输出命令。

  • '%x\n'：是格式控制字符串，表示将后面的参数按十六进制格式输出，并在末尾添加换行符。

  • 4558：是要格式化输出的整数。

    [root]# printf ‘%x\n’ 4558
    11ce

命令 ：jstack 4380|grep -A 100 11ce

通过jstack打印进程4380的堆栈信息，并只过滤出线程11ce的堆栈信息

命令含义：使用 jstack 来打印指定 Java 进程（PID为4380）的线程堆栈信息，然后使用 grep 过滤输出，查找包含特定字符串 “11ce” 的行，并打印该行及其后续100行的内容。

注：

  • jstack 4380：使用 jstack 命令获取 Java 进程 4380 的线程堆栈信息。
  • |：管道符，将 jstack 的输出传递给下一个命令。
  • grep -A 200 11ce：使用 grep 过滤包含字符串 “11ce” 的行，同时打印每个匹配行的后续100行内容（包括匹配行本身）。
"org.springframework.kafka.KafkaListenerEndpointContainer#0-0-C-1" #130 prio=5 os_prio=0 tid=0x00007f922eccd800 nid=0x11ce runnable [0x00007f91c80be000]
   java.lang.Thread.State: RUNNABLE
	at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
	at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
	at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
	at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
	- locked <0x0000000088383dc0> (a sun.nio.ch.Util$3)
	- locked <0x0000000088383db0> (a java.util.Collections$UnmodifiableSet)
	- locked <0x0000000088383d68> (a sun.nio.ch.EPollSelectorImpl)
	at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
	at org.apache.kafka.common.network.Selector.select(Selector.java:869)
	at org.apache.kafka.common.network.Selector.poll(Selector.java:465)
	at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:563)
	at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:265)
	at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:236)
	at org.apache.kafka.clients.consumer.KafkaConsumer.pollForFetches(KafkaConsumer.java:1292)
	at org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1233)
	at org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:1206)

其中第一行中 nid=0x11ce，此处就是我们上面16进制线程号：11ce。所以此条堆栈对应的代码行数，即为耗费CPU比较高的线程对应的代码(上面堆栈仅为示例)。

三.内存利用率过高问题定位

1.内存过高代码定位

内存过高和CPU过高一样，都可以用上述方法定位，在下方%MEM列，即表示内存占用率，找出对应的PID，重复上面操作即可定位。

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND\
4380 root      20   0 9415956 2.350g  26772 S  10.2 91.4 426:14.30 java\

2.设置java启动参数出现OOM自动打印堆栈

在服务器上建立好路径，比如：/usr/local/app/logs，然后当服务发生OutOfMemoryError（OOM）内存溢出时，会自动打印堆栈信息到dump.hprof文件中，那时我们只需要分析此文件即可定位问题。

nohup java -XX:HeapDumpPath=/usr/local/app/logs/dump.hprof -XX:+HeapDumpOnOutOfMemoryError-jar /usr/local/app/test-web.jar  --spring.profiles.active=pro >/dev/null 2>&1 &

3.分析堆文件

在jdk安装目录下，jdk1.8.0_60\bin下，有jvisualvm.exe工具，打开这个工具，点击文件->装入->文件类型选择hprof->选择dump.hprof。如下图：
在这里插入图片描述

如果有OOM会显示在概览中，并且堆栈信息也打印了。
在这里插入图片描述

特别提醒：

OutOfMemoryError（OOM）的堆栈信息通常只显示了导致内存不足的最终操作，而不一定反映了问题的根本原因。OOM 堆栈信息中的最上层可能只是触发了 Java 虚拟机报告内存不足的点，而不一定是导致内存不足的真正原因。即此工具分析结果只是压死骆驼的最后一根稻草，并不一定是导致内存溢出的原因，所以有时你还需要找到压死骆驼的那块大石头，而不要只盯着这跟稻草优化，比如有时候会显示垃圾回收GC线程占用内存过高，但GC可不是导致OOM的根因。大多数情况下，jvisualvm定位到的问题就是OOM的原因，但不全是，所以你要明白原因。

四.使用阿里巴巴Arthas诊断工具

1.Arthas能做什么？

Arthas有很多强大功能，本文只针对CPU和内存使用率过高的性能问题进行讲解，其他用法参考《官方文档》拓展阅读吧。

2.下载Arthas

如果服务器可以连接互联网，可以直接使用下面的命令下载，如果不能联网，可以下载jar包后上传到服务器。

curl -O https://arthas.aliyun.com/arthas-boot.jar

3.启动Arthas

java -jar arthas-boot.jar

启动时，需要手动选择要监控的java程序，如果只有一个，就输入“1”，如果多个，输入对应的序号数字即可，如图：
在这里插入图片描述

4.定位占用资源多的线程堆栈

使用命令打印出占用CPU的线程堆栈，即可定位问题，然后就具体情况具体分析了，每个人遇到的问题都是不一样的，这里只教学下排除问题的方法。以下是几个常用的命令：

①.查询最忙的3个线程，采样5000毫秒内的堆栈信息：

thread -n 3 -i 5000

5000毫秒为采样时间，如果不加-i 5000，那么默认是采样200毫秒，采样时间过短的话往往不太准确，因为采样本身也会占用CPU性能，所以可以适当延长一下

②.查询当前阻塞其他线程的线程：

thread -b

如果有堵塞的线程会打印出来，如果没有则不会打印出结果。比如一些kafka消费类的线程，会一直处于堵塞状态，这种其实也是正常的，并不是有堵塞的线程，就要去解决优化。我们要看看那些不应该长时间堵塞的线程，为啥出现了堵塞。

注：thread命令使用参考《官方文档-thread命令》

③.查看JVM信息，下面三个命令都可以：
jvm
sysprop
sysenv

如果忙碌线程中，长时间出现GC，那就开启GC日志，

XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log

看看是否出现了Full GC，Full GC日志示例：


2024-01-04T12:34:56.789-0500: [Full GC (System.gc()) [PSYoungGen: 0K->0K(5120K)] [ParOldGen: 4096K->4096K(10240K)] 4096K->4096K(15360K), [Metaspace: 1234K->1234K(8192K)], 0.0123456 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

如果出现了Full GC，那就用上文提到的jvisualvm.exe分析堆文件，找出占用内存大的对象，并优化。

总结

本文介绍了通过系统日志、java JDK工具、JVM参数、linux系统命令、Arthas诊断工具等方法，定位和解决线上CPU使用率过高、内存使用率过高的方法，大家可以根据自己的环境灵活搭配使用上述方法，解决性能问题。排查性能问题需要不断的积累经验的过程，新手可能感到无从下手，结合本文提到的工具，多尝试、多总结，遇到性能问题不要侥幸，敬畏墨菲定律，不要想着重启下就能解决，重启大法好，但不能提升你解决问题的能力。所以出现偶发的性能问题一定要及时去定位，不然就像定时炸弹一样，在你下班时间引爆。工作学习上要积极主动些，上工治未病。

大脑补丁
关注
  • 23
    点赞
  • 踩
  • 27
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
LINUX类主机JAVA应用程序占用CPU、内存过高分析手段
12-11
当用户量过大，或服务器性能不足以支持大用户量，但同时又得不到扩容的情况下，进行性能分析，并对系统、应用、程序进行优化显得尤为重要，也是节省资源的一种必不可少的手段。目前大多数运维产品都基于JAVA语言开发，读过本文分享的在linux环境下对JAVA的性能分析手段会让你受益匪浅。
java cpu 内存占用高 问题 模拟并排查
03-29
java cpu 内存占用高 问题 模拟并排查 https://blog.csdn.net/jiankunking/article/details/79749836 https://blog.csdn.net/jiankunking/article/details/79749483
内存飙高问题如何排查？
最新发布
cj_eryue的博客
02-29 1023
内存飙高如果发生在java进程上，一般情况是因为创建了大量对象导致，持续飙高说明垃圾回收跟不上对象创建的速度，或者内存泄漏导致对象无法被回收！排查中涉及到如下命令：jstat -gc pid 1000 查看gc情况，时间等信息，每隔一秒打印一次jmap -histo pid | head -20 查看堆内存占用空间最大的钱20个对象类型jmap -dump:live,format=b,file=/home/chenjian/myheapdump.hprof pid 导出堆内存快照。
Java应用无响应、内存飙升、CPU飙升排查
学习笔记
07-26 5530
排查Java无响应，内存溢出等问题。
手把手教你如何定位服务内存溢出，来看这里
weixin_40648256的博客
05-07 2547
定位Java服务内存溢出问题需要使用多种方法和工具，包括设置JVM参数、分析堆内存转储文件和使用代码分析工具。通过这些方法和工具可以快速定位和解决内存溢出问题，提高服务的稳定性和可靠性。
Java线上项目cpu过高的排查思路
cyh的博客
01-28 5024
项目介绍 是给银行做的一个征信系统项目，业务如图 代码如下 问题 项目在linux运行一段时间后，发现cpu占用率越来越高，最终达到100% 排查步骤 1.top命令找到cpu占用高的进程号 发现进程号为2732 2.查看进程的所有线程信息，记下占用最高的线程 执行命令，单独监控该进程 top -p 2732 在界面按下H，获取当前进程下所有线程信息 占用cpu最高的线程为2734 **3.将第2步得到的线程号转化为十六进制 ** 将2734转化为十六进制数 **4.查看进程堆栈信息 ** 根据第1
【Java】 服务器cpu过高如何排查和解决？
DreamSun的博客
07-20 1万+
对于互联网公司，线上CPU飙升的问题很常见（例如某个活动开始，流量突然飙升时），按照本文的步骤排查，基本1分钟即可搞定！特此整理排查方法一篇，供大家参考讨论提高。线上系统突然运行缓慢，CPU飙升，甚至到100%，以及Full GC次数过多，接着就是各种报警：例如接口超时报警等。此时急需快速线上排查问题。不管什么问题，既然是CPU飙升，肯定是查一下耗CPU的线程，然后看看GC。
java 高cpu占用问题解决
一杯咖啡半杯糖的博客
07-06 8376
这是一次真实的问题解决，献给同样被高cpu问题困扰的大家。 背景： 某天内部用户反馈，前端界面加载特别慢。测试了网络，日志，代码，感觉都正常，但是程序在使用查询sql的时候就是不返回。 1、进到linux容器中执行 top命令，结果发现高cpu占用，其中pid 为1的正是我们的java程序 2、执行命令找出占用CPU最高的线程 top -Hp pid 显示的新pid都是线程，找到占用cpu最高的线程号 3、把线程号转换为16进制，便于在jstack中查询 pr...
【故障处理】java程序cpu飙高如何排查
run_boy_2022的博客
05-25 3637
我们可以使用命令 cat jstack_result.log | grep "java.lang.Thread.State" | sort -nr | uniq -c 来对 jstack 的状态有一个整体的把握，如果 WAITING 之类的特别多，那么多半是有问题啦。当然更常见的是我们对整个 jstack 文件进行分析，通常我们会比较关注 WAITING 和 TIMED_WAITING 的部分，BLOCKED 就不用说了。这里介绍如何使用原生top命令来做定位具体代码的位置处理。
Java线上服务CPU、内存飙升问题排查步骤！
伤心的辣条
05-30 8228
如果是Full GC次数过多，那么通过 jstack得到的线程信息会是类似于VM Thread之类的线程，而如果是代码中有比较耗时的计算，那么我们得到的就是一个线程的具体堆栈信息。下面将总结一些具体的排查步骤。首先找到该接口，通过压测工具不断加大访问力度，如果说该接口中有某个位置是比较耗时的，由于我们的访问的频率非常高，那么大多数的线程最终都将阻塞于该阻塞点。这是比较麻烦的一种情况，因为一般来说，其消耗的CPU不多，而且占用的内存也不高，也就是说，我们通过上述两种方式进行排查是无法解决这种问题的。
Java进程CPU使用率高排查
12-22
近期java应用，CPU使用率一直很高，经常达到，通过以下步骤完美解决，分享一下。 　　1.jps 获取Java进程的PID。 　　2.jstack pid >> java.txt 导出CPU占用高进程的线程栈。 　　3.top -H -p PID 查看对应进程的哪个线程占用CPU过高。 　　4.echo “obase=16; PID” | bc 将线程的PID转换为16进制。 　　5.在第二步导出的Java.txt中查找转换成为16进制的线程PID。找到对应的线程栈。 　　6.分析负载高的线程栈都是什么业务操作。优化程序并处理问题。
MySQL性能瓶颈排查定位实例详解
12-15
本文实例讲述了MySQL性能瓶颈排查定位的方法。分享给大家供大家参考，具体如下： 导读 从一个现场说起，全程解析如何定位性能瓶颈。 排查过程 收到线上某业务后端的MySQL实例负载比较高的告警信息，于是登入服务器检查确认。 1. 首先我们进行OS层面的检查确认 登入服务器后，我们的目的是首先要确认当前到底是哪些进程引起的负载高，以及这些进程卡在什么地方，瓶颈是什么。 通常来说，服务器上最容易成为瓶颈的是磁盘I/O子系统，因为它的读写速度通常是最慢的。即便是现在的PCIe SSD，其随机I/O读写速度也是不如内存来得快。当然了，引起磁盘I/O慢得原因也有多种，需要确认哪种引起的。 第一步，我们一
java获得CPU使用率,系统内存,虚拟机内存等情况工具类
11-18
通过jmx可以监控vm内存使用,系统内存使用等 ，特点是通过window和linux命令获得CPU使用率。
Android编程实现获取系统内存、CPU使用率及状态栏高度的方法示例
01-04
本文实例讲述了Android编程实现获取系统内存、CPU使用率及状态栏高度的方法。分享给大家供大家参考，具体如下： DeviceInfoManage类用于获取系统的内存,CPU的信息，以及状态栏的高度 import java.io.BufferedReader...
快速定位java程序cpu过高原因
10-10
将定位cpu过高的命令做了一个整理，直接执行脚本定位问题
Java数组转List的三种方式及对比
热门推荐
五道口
03-18 36万+
本文介绍Java中数组转为List三种情况的优劣对比，以及应用场景的对比，以及程序员常犯的类型转换错误原因解析。
RESTful介绍和使用教程
五道口
07-21 10万+
REST（Representational State Transfer）表象化状态转变（表述性状态转变），在2000年被提出，基于HTTP、URI、XML、JSON等标准和协议，支持轻量级、跨平台、跨语言的架构设计。是Web服务的一种新的架构风格（一种思想）。...
Java定时器（实现每月1号、每日、每15分钟自动执行任务）
五道口
03-20 4万+
需求： 在tomcat中，每月一号、每日、每分钟自动执行指定的任务。 开发环境： java1.7+ tomcat 实现思路： 在tomcat中，添加监听器，在监听器中设置定时任务。 1.监听： 新建监听类implents ServletContextListener，实现其中的方法即可。 讲解： 1.1：创建一个基准时间defaultdate（每日8点），用于参照，在此时间以...
生产环境CPU100%如何排查
02-24
回答： 首先，检查服务器上的任务，查看哪些程序正在占用CPU资源。其次，查看服务器上的日志文件，以及与服务器连接的外部设备，以找出可能导致CPU使用率增加的原因。最后，有必要检查服务器上的硬件设置，确保没有发生任何内存或硬盘问题。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值