
1 JohnZorn OP  |
2 dqzcwxb Jun 2, 2022 下个 arthas 找到负载高的线程,查到对应代码然后解决就完事了 |
3 RedBeanIce Jun 2, 2022 按照百度的 jvm 100%问题排查。去排查呗 |
4 cheng6563 Jun 2, 2022 jstack 出不来的话直接用 arthas attach 应该也不行。 直接项目启动时用 arthas agent 启动,然后持续输出日志吧。 |
5 RedBeanIce Jun 2, 2022 @RedBeanIce 我错了。。。楼主已经排查过了。答非所问 |
6 zeni123 Jun 2, 2022 试一下调大 eden space (*1.5 - 2.0) 看看怎样,eden space 应该和负载高度相关. 下面是我的猜想, 假如你经过排查后发现 CPU 占用率不是业务逻辑的线程导致的 那么 eden 可能释放了 但是又因为高负载被占满了,所以看上去一直不释放。 估计 eden 释放一次只能释放 10% 而不是 90%。YGC 效率不高,造成 YGC 一直工作 CPU 占用率高。 |
9 xiaohusky Jun 2, 2022 @RedBeanIce 请问大佬,哪里有参考文档呢?我没谷歌出来,想学习一下 |
10 chendy Jun 2, 2022 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=路径 等一个 oom 吧,感觉是内存泄漏 |
12 zeni123 Jun 2, 2022 @choice4 我的思路其实就是负载太高了 new 的对象多了 内存不够用了。 和调优无关 GangWorker 就是是 gc 线程吧。gc 线程频繁启动 相当于 rateLimiter 限制你负载的处理速度 -Xmx2g -Xms2g -Xmn1g 和 -Xms4g -Xmx4g -Xmn2g 它们能处理的负载可能是不一样的 ,你要把负载限制在同一个值再来调整对比。 以上都是推测 |
13 JohnZorn OP |
14 letianqiu Jun 2, 2022 @choice4 这个其实就是 GC 在 copy 活着的对象。你有没有加上-Xlog:gc=info ,甚至用-Xlog:gc=debug ,看 gc 的 log ? |
15 alsas Jun 2, 2022 试试看 G1GC 效果很好 |
16 1194129822 Jun 2, 2022 java 具体什么小版本?什么垃圾收集器?感觉这个现象很明显是 eden 区直接晋升老年代,老年代有空间但是需要进行内存整理( full gc )才能确保晋升,所以 CPU 一直很高的占用。当然只是可能,具体还要看环境、甚至代码。但是很少有应用需要新生代设置一半堆内存,你把-Xmn1g 去掉或者改小一点看一下。 |
17 JohnZorn OP @1194129822 最初始的内存配置是 -Xmn768m -Xms2g -Xmx2g ,后来发现是新生代满后就尝试对内存放大,但是没效果,即便新生代最后放到 2g 一样打满 |
18 JohnZorn OP @1194129822 内存整理的话,他这个时间也太长了,只要达到这个状态,一晚上不管他的话第二天还是打满的 cpu 。。。 |
19 zizon Jun 2, 2022 @choice4 看这 3s 一次的 jstat 就根本没动过...估计一直反复在 vm operation 里出不来... 可以复现的话加个 PrintSafepointStatistics 看看是哪些 vm op... 还有几个 un-document 的参数是控制 vm op 详情和采样频率的,但一时想不起了. 之前有个类似的 freeze 的案例是有人写了个 jstack -L 的 cron job,一分钟一次... -L 导致会单线程爬所有线程的锁关系. 也可能不是-L,但是个 print lock detail 的相关 flag. |
20 yidinghe Jun 2, 2022 via Android 这有点过分啊,说明程序正在大量创建临时对象。针对性优化也不难,就是检查哪些对象其实可以留着复用,延长它们的生命周期。 |
21 luozic Jun 3, 2022 这种可以通过 jmc 工具查看的,visualvm 也行,这种通过 jdk 内置探针查看信息的工具 https://jdk.java.net/jmc/8/ https://visualvm.github.io/ |
22 JohnZorn OP |