CPU负载过高排查发现是由于GC占了大量CPU该怎么解决

已于 2024-12-10 09:35:10 修改
阅读量171 收藏
点赞数 2
文章标签： java
于 2024-12-08 10:52:50 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/Icangofly/article/details/144322856
版权

服务器上正常运行java程序时，出现cpu负载过高，通过top -Hp 命令发现其中是由于几个ParGC线程占据着大量cpu导致最终其他计算线程无法正常进行，有什么解决的办法吗

目前刷到的解决办法是调高jvm的xmx/xms/xmn的启动参数，但是在该服务器上调高启动参数之后，运行一段时间后还是会出现相同的错误，这是说明服务器不行吗

日月-星辰
关注
CPU占用过高故障排查实战
悦分享
11-18 254
Java 线程池以有界队列的线程池为例，当新任务提交时，如果运行的线程少于 corePoolSize，则创建新线程来处理请求。最后定位问题是在tomcat中的catalina.out控制台日志输出过大，造成磁盘空间占满，然后系统无法继续写日志，从而导致刚好dubbo服务打印的日志一直处于死锁状态，该线程陷入死循环，大量消耗cpu，最终的结果是内存溢出，杀死进程了。将控制台打印的日志给禁用掉，并限制打印日志的大小，因为我的日志里面有打印base64位的图片日志，该日志所需空间太大，所以对日志禁用及限制。
linux杀掉cpu使用率高的进程,线上linux系统故障排查之一：CPU使用率过高
weixin_29786123的博客
04-28 1498
一个应用占用CPU很高，除了确实是计算密集型应用之外，通常原因都是出现了死循环。下面我们将一步步定位问题，详尽的介绍每一步骤的相关知识。一、通过top命令定位占用cpu高的进程执行top命令得到以下结果：top命令执行结果通过上图可以明显看出进程PID41843占用cpu过高，明显存在问题，定位到了进程id。当然如果你想只观察进程PID41843的CPU和内存以及负载情况，可以使用以下命令top ...
CPU飙高，频繁GC，怎么排查？
ai_goodStudent的博客
01-15 3186
本文转自 处理过线上问题的同学基本上都会遇到系统突然运行缓慢，CPU 100%，以及Full GC次数过多的问题。当然，这些问题的最终导致的直观现象就是系统运行缓慢，并且有大量的报警。 本文主要针对系统运行缓慢这一问题，提供该问题的排查思路，从而定位出问题的代码点，进而提供解决该问题的思路。 对于线上系统突然产生的运行缓慢问题，如果该问题导致线上系统不可用，那么首先需要做的就是，...
由于YOUNG GC导致 cpu过高
qq_27130997的博客
11-15 1996
1 背景分析 1 线上服务器CPU使用率突然达到90%，发生告警，现在让你来排查 2 当你不知道何种情况导致的 2 解决思路 1. 1 查看服务使用java进程号 jps -l 2.2 查看GC发生频率 jstat -gcutil Java进程号 多少毫秒执行一次 ...
一次JVM_OLD区占用过高、频繁Full GC的解决过程
热门推荐
关于代码的那些事
10-31 1万+
最近，公司网站频繁报警，JVM_OLD占用过高，线上访问超时严重，针对这个问题着实头疼了一把，不过最终还是解决了，下面说下解决的过程。 1，首先 登到线上机器上去，top命令，查看当前机器的负载，查看当前哪个进程在消耗资源。 Shell 1 top 找到CPU或者内存占用过高的那个进程。发现有一个进程，CPU居高不下，保留进程id 2，top命令，...
裂开，JVM疯狂GC导致CPU飙高
Java圈全能架构师的博客
10-03 1576
背景 线上web服务器不时的出现非常卡的情况，登录服务器top命令发现服务器CPU非常的高，重启tomcat之后CPU恢复正常，半天或者一天之后又会出现同样的问题。解决问题首先要找到问题的爆发点，对于偶现的问题是非常难于定位的。 重启服务器之后只能等待问题再次出现，这时候首先怀疑是否某个定时任务引发大量计算或者某个请求引发了死循环，所以先把代码里面所有怀疑的地方分析了一遍，加了一点日志，结果第二天下午问题再次出现， 这次的策略是首先保护案发现场，因为线上是两个点，把一个点重启恢复之后把另一个点只下线不
JVM频繁FullGC以及CPU占用过高问题
weixin_45000157的博客
08-22 1722
最近线上某个服务所有接口突然响应很慢，并且超时，一开始以为是网络的问题，分时段测试了一下，发现并没有太大问题，于是把问题聚焦到了服务本身，用top命令简单看下，CPU直接飙升到了800+%，好家伙，应该是存在明显问题了，经过一阵分析，问题解决，故记录一下排查过程，截图已经是解决后的效果，懒得再把代码换回去了，说明下思路即可。运气好的话，一般到这里，基本就能看出来出了问题的代码，如果没看出来，多查看几个线程的状态，对比分析一下，这里的截图只是做演示，所以是RUNNABLE状态，如果是wait，就要注意了；
GC实战—浮动内存导致的CPU过高调优
weixin_34348805的博客
02-20 340
哥伦布在2019春节战役期间，由于接入的应用越来越多，对系统性能要求越来越高，提高系统的吞吐率，以及提升性能，是我们春节战役期间必须要做的事情。 系统的性能优化不单单是对JVM的参数调优，也不是某一段代码的改造，而是一个系统的工程，往往会出现牵一发而动全身，简单的解决，很容易治标不治本从而掩盖问题的本质，而这些深藏的问题才是我们解决问题关键。 本次的浮动...
生产稳定：JVM调优- java进程，JVM频繁GC，导致CPU占用、内存占用过高过高定位和排查
做技术，贵在学习与坚持！
11-10 2536
CPU占用过高定位和排查 1、查到耗CPU的线程id，top命令找出最高占用的进程（command为java） top -H ps -mp pid -o THREAD,tid,time 2、使用命令将线程id（tid）转换为十六进制 printf "%x\n" tid 3、通过进程id和线程id查看线程栈内存 jstack pid |grep tid -A 30 4、通过进程id导出堆内存（dump信息） jmap -dump:format=b,file=name.
一次GC线程占用系统CPU过高处理过程
hyl29742的博客
12-12 4806
因为测试人员报告说，最近订单系统总是超时，要重启才能恢复正常，但是第二次复现的时间不固定。 然后先是查看下应用状态是否正常，没有问题。 然后查看日志，发现有很多交易报超时。 仔细查看超时的日志，发现什么类型的交易都有，而且超时的地方也不固定，更像是系统或者架构层面的错误。 赶紧看下（ps ux）linux系统的状态。发现订单应用的CPU已经100%，但是内存还有剩余，内存占用 大概30...
如何有效判断与排查Java GC问题
最新发布
张彦峰的博客
03-02 3万+
本文介绍了Java垃圾回收（GC）的基本原理及其优化策略。通过分析GC的工作机制，探讨了常见的GC类型、内存管理模型及其对应用性能的影响。文章还详细阐述了如何通过调整JVM参数、选择合适的GC算法和分析GC日志来优化内存回收效率。通过这些实用的优化方法，开发者可以有效减少GC暂停时间，提高应用的响应速度和吞吐量。
JVM调优（二）——CPU高达90%，如何定位与排查
peach_garden的博客
07-02 1415
服务CPU高达90%，如何定位与排查；top & jstack组合使用
linux 排查cpu负载过高原因
09-20
Linux排查CPU负载过高的原因通常有以下几个方面： 1. 进程负载过高：可以通过使用top命令或htop命令查看当前系统的进程状态，找到最耗CPU的进程，并检查其是否正常运行。如果是某个进程导致的负载过高，可以进一步...
解决CPU占用100%，JVM年轻代GC频率高
Tiny_Demon的博客
05-18 1362
执行 jstack 进程号 | grep 线程ID 查找某进程下 ,线程ID（jstack堆栈信息中的nid）=0xa的线程状态。也可以使用jmap -heap 进程ID查看一下进程的堆内从是不是要溢出了，特别是老年代内从使用情况一般是达到阈值(具体看垃圾回收器和启动时配置的阈值)就会进程Full GC。例如，printf “%x\n” 线程ID ，打印：16b1，那么在jstack中线程号就是16b1。后续查看线程堆栈信息展示的都是十六进制，为了找到咱们的线程堆栈信息，咱们需要把线程号转成16进制。
一次Full GC导致CPU飙升的排查过程
汐日南莘的博客
04-10 2589
一次FULL GC导致CPU飙升，系统卡顿的问题排查过程，JVM, FULL GC
系统CPU飙高和频繁GC，我要怎么排查
weixin_43870079的博客
09-04 1203
1. Full GC次数过多 相对来说，这种情况是最容易出现的，尤其是新功能上线时。对于Full GC较多的情况，其主要有如下两个特征： 线上多个线程的CPU都超过了100%，通过jstack命令可以看到这些线程主要是垃圾回收线程 通过jstat命令监控GC情况，可以看到Full GC次数非常多，并且次数在不断增加。 首先我们可以使用top命令查看系统CPU的占用情况，如下是系统CPU较高的一个示...
因Full GC导致CPU飙升到100%问题排查记录
翎野君的博客
07-16 1442
背景 提供了一个商品信息查询接口，此接口中会从Redis缓存中读取一个大对象列表出来，然后再根据传入的参数，对大对象列表进行过滤，进而得到最终的返回结果。 这里是一个比较典型的触发CPU飙高的场景，单次调用会生成大对象导致占用大量的年轻代空间。如果在业务高峰期，调用这个商品查询接口的频次很高的话，会导致堆内存飙升，老年代空间飙升，最终导致Full GC，如果不停地请求这个接口，会发现GC垃圾回收...
项目实战典型案例15——高并发环境下由于使用全局变量导致数据混乱 高并发环境下对象被大量创建，导致GC并且CPU飙升
理想主义的花最终会盛开在浪漫主义的土壤里，我的热情永远不会熄灭在现实的平凡之中，我们终将上岸，阳光万里。
03-17 1455
1. 在项目开发过程中，对于公共变量的使用一方面需要慎重，需要考虑是否有并发，多线程的情况，然后根据实际情况选择对应的处理措施。 2. 实例化类，也需要慎重，实例化类是有有必要。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值