一次FullGC 血案侦破过程

╰半橙微兮° 2024-04-19 10:28 0阅读 0赞

一、持续报警

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plcm92cHA_size_16_color_FFFFFF_t_70][]

恢复

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plcm92cHA_size_16_color_FFFFFF_t_70 1][]

2、查后台日志

top

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plcm92cHA_size_16_color_FFFFFF_t_70 2][]

jstat -gc pid

![20190917100936892.png][]

jstat -gc()capacity -pid

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plcm92cHA_size_16_color_FFFFFF_t_70 3][]

查看head（关于Java Dump日志重点关注点，见这篇文章[《三个实例分析Java Thread Dump日志》][Java Thread Dump]

jstack pid

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plcm92cHA_size_16_color_FFFFFF_t_70 4][]

这种信息量太大且杂乱，不易定位问题点，加grep 搜索关键词 waiting on 定位下

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plcm92cHA_size_16_color_FFFFFF_t_70 5][]

3、峰回路转，问题出在这儿

经过上述一顿查找、分析，似乎也没发现大的嫌疑点，内存、CPU占比并不高，也没有报OOM异常，问题出在哪儿呢？

回过头来，我们看告警值是8，这个8是怎么来的呢？这就与load average与CPU个数有关了。

系统平均负载（load average）被定义为在特定时间间隔内运行队列中的平均进程树。如果一个进程满足以下条件则其就会位于运行队列中：

(通俗的说，运行队列中的进程树正在消耗内存和CPU资源，从而能算出消耗资源的比例。）

**        ** \- 它没有在等待I/O操作的结果

- 它没有主动进入等待状态(也就是没有调用'wait')

- 没有被停止(例如：等待终止)

例如：

\[root@opendigest root\]\# uptime

7:51pm up 2 days, 5:43, 2 users, load average: 8.13, 5.90, 4.94

命令输出的最后内容表示在过去的1、5、15分钟内运行队列中的平均进程数量。

而告警是指“每CPU活动进程数量”，= 总进程数量/CPU数量

一般来说只要每个CPU的当前活动进程数不大于3那么系统的性能就是良好的，如果每个CPU的任务数大于5，那么就表示这台机器的性能有严重问题。对于上面的例子来说，假设系统有两个CPU，那么其每个CPU的当前任务数为：8.13/2=4.065。这表示该系统的性能是可以接受的。

除此外，还要了解下谁触发了FullGC：（1）程序调用System.gc时可以触发；（2）系统自身来决定GC触发的时机。系统判断GC触发的依据：根据Eden区和From Space区的内存大小来决定。当内存大小不足时，则会启动GC线程并停止应用线程。

猛然想起，迁移到新环境，tomcat都是按默认的配置，是不是设置的内存太小呢？立即行动，在tomcat/bin/catalina.sh修改内存配置参数：

**JAVA\_OPTS="-server -Xms4g \-Xmx4g -Xmn2500m \-verbose:gc -Xloggc:/opt/gc\_%p.log -XX:+PrintGCDetails**

如何理解上述这段配置，借用《深入理解虚拟机》来看看：

*JVM 中最大堆大小有三方面限制: 1.相关操作系统的数据模型(32-bt还是64-bit)限制; 2.系统的可用虚拟内存限制; 3.系统的可用物理内存限制. 在32位系统下,一般限制在1.5G~2G;64为操作系统对内存无特定限制.  *

*机器配置：8G内存   4核CPU*

*典型设置:   
java -Xmx4g -Xms4 -Xmn2500m -Xss256m  
   -Xmx4g:设置JVM最大可用内存为4g.  
   -Xms4g:设置JVM促使内存为4g.此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存.  
   -Xmn2g:设置年轻代大小为4G.*

*整个堆大小=年轻代大小 + 年老代大小 + 持久代大小.持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小.此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8*

设置完重启tomcat，立马见效。告警消失了一大半，但还是有在报的，这是什么原因呢？既然硬件方面的原因解决，那肯定就出在代码上了。

cat pid.log |grep "System.gc()"

果然查出一大堆显性调用System.gc的代码，

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plcm92cHA_size_16_color_FFFFFF_t_70 6][]

看来运维小哥还得加油呀。于是在tomcat的catalina.sh加上将system.gc调用的禁用限制：\-XX:+DisableExplicitGC

重启运行一段时间后，再也没报FullGC的告警了。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plcm92cHA_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/07498315888247098f4556182b71262b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plcm92cHA_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/805be27b0a0b40c080c93ced1e3fc26f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plcm92cHA_size_16_color_FFFFFF_t_70 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/c0faa57f273c4358bb86846783d48971.png
[20190917100936892.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/04cbf2aaddd54145bc4496244cd042fe.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plcm92cHA_size_16_color_FFFFFF_t_70 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/574d41e39f7344c09ab7cc09ffaa043a.png
[Java Thread Dump]: https://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plcm92cHA_size_16_color_FFFFFF_t_70 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/c790879408fe4360bd6117f53e07fc36.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plcm92cHA_size_16_color_FFFFFF_t_70 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/3d4e5bd1a8524fbbb02da5121dbdcfa9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plcm92cHA_size_16_color_FFFFFF_t_70 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/0bbd5b4762c24ecdb54fb4032a94eb09.png