2021-08-19

最新推荐文章于 2023-06-03 22:11:41 发布
最新推荐文章于 2023-06-03 22:11:41 发布
阅读量612 收藏 2
点赞数 1
分类专栏： JVM 文章标签： jvm java linux
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lydianiu/article/details/119808987
版权

linux java程序cpu占用高跟踪

问题描述：

压测过程中，发现tomcat服务器不灵活，刷新（控制台）页面长时间转圈，无响应。需要找出CUP占用较高原因，进行分析并且优化

解决过程：

1. top命令检查CPU占用较高进程

top

发现pid为17084的java进程占用服务器cpu很高
请添加图片描述

2. 命令 ps -mp 【替换为进程ID PID】 -o THREAD,tid,time，查看该进程占用高的线程；

ps -mp 17084 -o THREAD,tid,time | sort -rn

发现tid为23311的线程占用CPU较高且吃香时间较长，图2效果更明显，是调优前效果，作为对比图用

图1在这里插入图片描述
图2
请添加图片描述

3. 命令printf “%x\n” pid，把tid转换为16进制；

printf “%x\n” 23311

输出结果为5b0f
在这里插入图片描述

4. 命令jstack pid| grep tid（十六进制） -A 10 -B 30，查看进程pid为17084且tid为5b0f的线程的栈信息 前后30行；

jstack 17084 | grep 5b0f -A 10 -B 30

在这里插入图片描述
从报错信息中可以看到为，栈异常导致频繁GC，想要继续追踪其他参数，进一步确认问题

图2为效果更明显图
请添加图片描述

5.命令jmap -histo，查看进程里占用的对象情况，我这里截取占用内存最多的前30条日志；

jmap -histo 17084 | sort -n -r -k 2 | head -30

由图基本上问题已经定位到了，走查代码发现：主要应该是频繁分发那里的代码逻辑，创建了太多得对象，导致大量引用一直存活，且越来越多(GCRoot可达)，从6中图2可以看到，青年代和老年代占满，频繁full jc STW，压测请求堆积压垮服务器。
在这里插入图片描述

也可以通过

6. 垃圾回收问题，使用jstat -gcuti pid命令，查看进程Java内存分布及回收情况来验证，间隔1秒打印一次，共5次；

jstat -gcutil统计gc信息显示列名具体描述

jstat -gcutil 17084 1s 5

从图中相同代码，不同时间段产生的YGC和FGC的次数可以看出GC频繁，且FGC频繁（pid为33745的进程效果比较明显，作为对比图使用）
在这里插入图片描述
S0：年轻代中第一个survivor(幸存区)已使用的占当前容量百分比

S1：年轻代中第二个survivor(幸存区)已使用的占当前容量百分比

E：年轻代中Eden(伊甸园)已使用的占当前容量百分比

O：old代已使用的占当前容量百分比

M：metadate已使用的占当前容量百分比

YGC：从应用程序启动到采样时年轻代中gc次数

YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)

FGC：从应用程序启动到采样时old代(全gc)gc次数

FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)

GCT：从应用程序启动到采样时gc用的总时间(s)

  • 6.1

    从jstat -gcutil信息来看，可以看到GC是ParallelScavenge（-XX:+UseParallelGC，在server class machine上这个是默认GC；以及有可能full GC用的是PSCompact）

  • 6.2
    ParallelScavenge有个默认打开的功能叫做adaptive size policy，在应用分配内存压力很大的时候有可能会把两个survivor space都收缩到最小（几乎为0），于是young gen基本上就整个都是eden，经历young GC能存活下来的对象就会直接晋升到old gen去，等到full GC的时候再看能不能回收。从 jstat -gcutil 的空间占用数据似乎是反映了这种情况

  • 6.3
    而ParallelScavenge在触发GC的时候，要么会触发单独的young GC，要么会触发young GC + full GC（这里是full GC前会关联触发一次young GC，这个行为由 -XX:+ScavengeBeforeFullGC 参数控制）。在触发full GC的时候，它有可能一口气循环接连触发多次full GC——如果跑了一次full GC还没回收到足够内存，那么会再“用力”一点再触发一次full GC，不行就再“用力”一点…（“用力”例如说ParallelScavenge的默认策略一开始是不会强迫清理SoftReference的，但需要再“用力”一点的时候就会清理SoftReference。）

  • 进程号pid为33745 的 jstat -gcutil 的GC次数数据似乎是反映了这种情况

  • 6.4 jstat -gc pid【进程号】也可以查看gc的信息，查看gc的次数，及时间

jstat -gc 17084

在这里插入图片描述
S0C：年轻代中第一个survivor（幸存区）的容量 (字节)
S1C：年轻代中第二个survivor（幸存区）的容量 (字节)
S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (字节)
S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (字节)
EC：年轻代中Eden（伊甸园）的容量 (字节)
EU：年轻代中Eden（伊甸园）目前已使用空间 (字节)
OC：Old代的容量 (字节)
OU：Old代目前已使用空间 (字节)
YGC：从应用程序启动到采样时年轻代中gc次数
YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)
FGC：从应用程序启动到采样时old代(全gc)gc次数
FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT：从应用程序启动到采样时gc用的总时间(s)

7. 垃圾回收问题，通过jmap -heap pid命令，打印栈情况来验证信息

jmap -heap 37745

从图中可以明显看到Old Generation使用率为93.17234102692849%
在这里插入图片描述
图2为效果显著图
请添加图片描述
Heap Configuration: #堆配置情况

  • MinHeapFreeRatio = 40 #堆最小使用比例

  • MaxHeapFreeRatio = 70 #堆最大使用比例

  • MaxHeapSize = 8589934592 (8192.0MB) #堆最大空间

  • NewSize = 1363144 (1.2999954223632812MB) #新生代初始化大小

  • MaxNewSize = 5152702464 (4914.0MB) #新生代可使用最大容量大小

  • OldSize = 5452592 (5.1999969482421875MB) #老生代大小

  • NewRatio = 2 #新生代比例

  • SurvivorRatio = 8 #新生代与suvivor的占比

  • MetaspaceSize = 21807104 (20.796875MB) #元数据空间初始大小

  • CompressedClassSpaceSize = 1073741824 (1024.0MB) #类指针压缩空间大小, 默认为1G

  • MaxMetaspaceSize = 17592186044415 MB #元数据空间的最大值, 超过此值就会触发 GC溢出( JVM会动态地改变此值)

  • G1HeapRegionSize = 2097152 (2.0MB) #区块的大小

Heap Usage: G1 Heap:

  • regions = 4096 # G1区块初始化大小
  • capacity = 8589934592 (8192.0MB) #G1区块最大可使用大小
  • used = 1557972768 (1485.7986145019531MB) #G1区块已使用内存
  • free = 7031961824 (6706.201385498047MB) #G1区块空闲内存
  • 18.137190118432045% used #G1区块使用比例G1
    Young Generation: 新生代
    Eden Space: #Eden区空间
  • regions = 670
  • capacity = 2699034624 (2574.0MB)
  • used = 1405091840 (1340.0MB)
  • free = 1293942784 (1234.0MB)
  • 52.05905205905206% used
    Survivor Space: #Survivor区
  • regions = 3
  • capacity = 6291456 (6.0MB)
  • used = 6291456 (6.0MB)
  • free = 0 (0.0MB)
  • 100.0% used
    G1 Old Generation: #老生代
  • regions = 72
  • capacity = 1589641216 (1516.0MB)
  • used = 146589472 (139.79861450195312MB)
  • free = 1443051744 (1376.2013854980469MB)
  • 9.221544492213267% used

8.垃圾回收问题，通过jstack命令，输出dump文件来验证

jstack -l 17804 > jstack.log

图1
请添加图片描述
图2
请添加图片描述

图3
请添加图片描述
图4
请添加图片描述

  • 问题分析

    通过图1，图2，图3可以看出：
    搜索java.lang.Thread.State: RUNNABLE ，共520次，说明所有线程都处于运行状态
    搜索java.net.SocketInputStream.socketRead0(Native Method) ，共500次，说明tomcat线程都阻塞在socket的read方法。
    搜索at com.telecomyt.mdm.sms.api.AuthApi.getMember(AuthApi.java:98)，共500次，此为业务代码
    根据日志查看业务代码:

String response = HttpUtil.postJson( authApi.ucenterProperties.getUrl() + authApi.ucenterProperties.getMemberInfoUri(),GsonUtil.toJson(memberDto),null)

使用的java.net的http请求，并且没有配置超时时间，默认超时时间为-1，导致服务调用超时却未关闭，大量占用线程，随着压测数据增加造成大量引用无法回收。
参考文档1
参考文档2

lydianiu
关注
  • 1
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Video_2021-08-19_160742.mp4
08-19
echarts
Schematic-tl494开关电源-2021-08-26
最新发布
09-18
《基于TL494的开关电源电路解析》 开关电源是一种高效能的电力转换设备，广泛应用于各种电子设备中。TL494是美国国家半导体公司（National Semiconductor）推出的一款集成电路，常被用作开关电源的控制器。...
【Linux】linux | top | java | jvm | 分析cpu占用过高 | 分析jvm堆栈信息
hgSuper的博客
08-23 1487
1、正式环境，cpu飙升，需要排查想原因2、正式环境： CentOS8 + jdk8 + nginx + java服务。
记录一次CPU占用过高的排查解决过程
xiaoye的博客
07-17 6916
最近部署在阿里云的项目总是无故被kill，并且登录到阿里云服务器查看的时候，发现卡的不行，怀疑可能cpu占用过高，就排查了一下，将排查过程进行记录。 1、先用top查看占用cpu较高的进程id(PID) 可以发现进程id为14073的进程一直占用98%的CPU 2、查看该进程中线程详细情况，ps -mp 进程ID -o THREAD,tid,time tid：线程id，.........
Jstack查询线程堆栈
weixin_37862824的博客
10-18 1万+
Jstack是什么？ jstack是java虚拟机自带的一种堆栈跟踪工具。 jstack主要用来查看Java线程的调用堆栈的，可以用来分析线程问题（如死锁）。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。 线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。 如果java程序崩溃生成core文件，jstack工
《Linux性能优化实战》笔记（三）—— CPU 上下文切换（下）
Hehuyi_In的博客
09-07 2055
上篇介绍了三种CPU 上下文切换以及它们可能造成的问题和原因，这一篇来看看在系统中如何发现CPU 上下文切换问题。 一、 查看上下文切换情况 主要使用两个命令：vmstat以及之前用过的pidstat。 1.vmstat # 每隔5秒输出1组数据 vmstat 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cach..
股权激励系列研究：阿里巴巴股权激励常态化_2021-08-19_UP金融科技控股.pdf
09-18
阿里巴巴作为全球知名的科技巨头，其在人力资源管理方面一直走在前列，尤其是在股权激励方面。股权激励是一种将公司股权作为奖励给予员工，以激发其工作积极性、提高忠诚度并推动长期发展的策略。...
2021-2022收藏的精品资料2021-2022年APQP全套表单——新产品质量策划进度计划APQP.doc
09-16
4. **设计输入评审**：APQP小组对设计输入进行评审，编写设计评审报告（TR-0701-08），以确保设计满足所有需求。 5. **确定设计目标和产品可靠性**：APQP小组设定新产品开发设计目标（TR-0701-09），同时开发部负责...
VW 80000 最新版 EN-2021.pdf
04-06
* Section 5.2：将“K-19 Climate components with watertight housing”改为“K-19 Climate test for components with watertight housings”。 * Section 5.4.11.2：将“and their combinations”改为“and status...
Linux 的一些常用命令
zhongqiong1286的博客
02-28 110
Linux 的一些相关命令 linux ： mkdir [文件名] 创建文件夹 cp 不加-r或者－R的时候，只拷贝文件，不拷贝文件夹；加上后则会拷贝文件夹——包括下一级的子文件夹，以及子文件夹中的子文件夹，余此类推 yum -y install lrzsz 安装rz shutdown -t now 文件编辑 保存退出 ESC :x :w 保存文件但不退出vi :w file 将修改另...
Linux CPU占用率100%排查
风是自由的，你也是
06-03 693
2.top -Hp [pid] 定位应用进程对应的线程 3.tidprintf “%x\n” [tid] 将tid转换为十六进制4.jstack [pid] | grep -A 10 [tid的十六进制] 打印堆栈信息。Linux服务器CPU占用率达到100%且一直居高不下，严重影响业务系统的正常使用。Ps aux | grep pod 然后直接kill掉。1.top 命令定位应用进程 pid。5.根据堆栈信息分析问题。
原来jdk自带了这么好玩的工具 ＞ 使用 jstack定位死循环
叶新东老师的博客
07-15 3365
什么是jstack jstack的主要作用是查看或者导出java线程的堆栈信息(快照)；用于堆栈跟踪，当我们使用jstack命令时，它会将指定进程内的所有线程中方法的调用栈打印出来。 线程快照是java虚拟机内每一个线程正在执行的方法堆栈的集合，生成线程快照的主要目的是用于定位线程出现问题的位置；常见的问题有 响应时间长 线程死锁 死循环 当线程停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道线程的执行过程中在后台做了哪些事，在等待哪些资源造成的卡顿。 使用方法 命令格式 jstack
将线程pid转成16进制_排查CPU利用率高的线程
weixin_42523104的博客
02-01 6259
在日常工作中,我们有时候需要排查线上问题,找出系统中CPU利用率最高的线程.当然,我们这里默认被排查的线程在JVM中,而不是其他非JVM的线程.涉及的命令$ top $ ps $ jstack思路1.根据top和ps命令查找到进程中CPU利用率最高的线程(内核级线程) 2.将内核级线程的十进制转成十六进制 3.根据jstack命令获取JVM级的线程信息方式一1.通过top命令找到CPU消耗(%CP...
java通过jstack命令查询日志深入理解
热门推荐
吴名氏的博客
03-20 12万+
java通过jstack命令查询日志深入理解
Java 开发，当cpu占用率100%，window和Linux分别如何定位问题
aaroncgt的博客
03-08 4602
Java开发如何解决cpu100%占用率的问题
java线程中的tid_jstack中的tid到底是什么意思呢
weixin_39953740的博客
02-26 2448
我们经常见到类似的jstack信息"main" #1 prio=5 os_prio=31 tid=0x00007fa63900c800 nid=0x1703 waiting on condition [0x0000700000219000]java.lang.Thread.State: TIMED_WAITING (sleeping)at java.lang.Thread.sleep(Native...
利用top,jstack定位程序问题
xiangpangzijiejinjun的博客
07-15 126
一、top -Hp pid -H 显示线程信息，-p指定pid 二、printf “%x\n” pid 查看pid的16进制 三、jstack 3147 | grep c60 -A 50 -A<显示行数> 或 --after-context=<显示行数> : 除了显示符合范本样式的那一列之外，并显示该行之后的内容。 -B<显示行数> 或 --before-context=<显示行数> : 除了显示符合样式的那一行之外，并显示该行之前的内容。 -C<显示
Java定位问题线程
生而为人我很抱歉
08-11 1089
3.将CPU占有率高的线程号转换为16进制（因为后面的jstack里的线程号是16进制）；6.从打印的信息中，找到第2步得到的线程号，看看这个线程在做什么。5.使用jstack [进程号] 打印当前的进程堆栈；不一定一次就能抓准线程状态，可以第2步时多看几个线程。1.通过top命令，查看CPU使用率高的进程；4.使用jps查看服务器的Java进程号；2.通过top获取的pid，使用。...............
select '2021-08-19', concat(date_add('2021-08-19',-6),'_','2021-08-19'), count(*) from ( select mid_id from ( select mid_id from ( select mid_id, date_sub(dt,rank) date_dif from ( select mid_id, dt, rank() over(partition by mid_id order by dt) rank from dws_uv_detail_daycount where dt>=date_add('2021-08-19',-6) and dt<='2021-08-19' )t1 )t2 group by mid_id,date_dif having count(*)>=3 )t3 group by mid_id )t4;
07-14
你的查询语句如下所示： ```sql select '2021-08-19', concat(date_add('2021-08-19',-6),'_','2021-08-19'), count(*) from ( select mid_id from ( select mid_id from ( select mid_id, date_sub(dt,rank) date_dif from ( select mid_id, dt, rank() over(partition by mid_id order by dt) rank from dws_uv_detail_daycount where dt>=date_add('2021-08-19',-6) and dt<='2021-08-19' ) t1 ) t2 group by mid_id,date_dif having count(*)>=3 ) t3 group by mid_id ) t4; ``` 这个查询语句是用于统计在日期范围内，满足某些条件的 mid_id 的数量。具体条件为：对于每个 mid_id，计算其 dt 与其在数据集中的排名之间的差值（date_dif），如果该差值出现至少3次，则将该 mid_id 计入统计。 查询结果将包括以下三个列： 1. '2021-08-19'：固定值，表示查询的日期。 2. concat(date_add('2021-08-19',-6),'_','2021-08-19')：将查询日期的前6天与查询日期拼接起来，形成一个字符串。 3. count(*)：满足条件的 mid_id 的数量。 请注意，这只是对你提供的查询语句的解释，如果你有其他问题或需要进一步的帮助，请随时告诉我。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值