工作中遇到的java 内存溢出,问题排查

2 篇文章 0 订阅

工作中遇到的java 内存溢出,问题排查

一、服务器配置及jvm运行参数

  1. CentOS release 6.4 (Final)
  2. MemTotal: 16333916 kB
  3. Intel(R) Xeon(R) CPU E7-4860 v2 @ 2.60GHz 8C
  4. -Xmx4096m -Xms4096m -XX:MaxPermSize=512m -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/heap/dump -server

    二、内存溢出场景
    800并发压测,一个小时,出现了内存溢出。
    三、问题排查
    通过查看gc情况可以看出当压测到半个小时的时候就出现了频繁FGC 如下图:

jstat -gc 7098 2000
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT   
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796242.3  90112.0 50428.6    348   25.295   8     37.453   62.748
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796242.3  90112.0 50428.6    348   25.295   8     37.453   62.748
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796242.3  90112.0 50428.6    348   25.295   8     37.453   62.748
17920.0 17920.0  0.0    0.0   1362432.0 1289751.1 2796544.0  2796395.6  84992.0 50428.6    348   25.295   8     43.144   68.439
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796395.6  84992.0 50428.6    348   25.295   9     43.144   68.439
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796395.6  84992.0 50428.6    348   25.295   9     43.144   68.439
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796395.6  84992.0 50428.6    348   25.295   9     43.144   68.439
17920.0 17920.0  0.0    0.0   1362432.0 1286917.0 2796544.0  2796468.2  80896.0 50428.6    348   25.295   9     49.018   74.313
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796468.2  80896.0 50428.6    348   25.295  10     49.018   74.313
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796468.2  80896.0 50428.6    348   25.295  10     49.018   74.313
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796468.2  80896.0 50428.6    348   25.295  10     49.018   74.313
17920.0 17920.0  0.0    0.0   1362432.0 1263355.4 2796544.0  2796045.4  76800.0 50428.6    348   25.295  10     54.915   80.210
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796045.4  76800.0 50428.6    348   25.295  11     54.915   80.210
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796045.4  76800.0 50428.6    348   25.295  11     54.915   80.210
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796045.4  76800.0 50428.6    348   25.295  11     54.915   80.210
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796127.0  73216.0 50428.6    348   25.295  12     60.780   86.075
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796127.0  73216.0 50428.6    348   25.295  12     60.780   86.075
17920.0 17920.0  0.0    0.0   1362432.0 1362432.0 2796544.0  2796127.0  73216.0 50428.6    348   25.295  12     60.780   86.075
17920.0 17920.0  0.0    0.0   1362432.0 600666.6 2796544.0  2796332.0  70144.0 50428.6    348   25.295  12     66.545   91.840

半个小时的时候就出现了8S一次FGC,YGC基本不变。通过GC情况就可以分析出,在老年代出现了一个大对象,一直回收不下去,这样就可以定位问题了,可以通过分析jvm的内存快照。

分析jvm内存dump文件

jmap -dump:format=b,file=/opt/appdump.bin 7098

生成了dump文件通过eclipse memory analysis 插件进行分析。由于dump文件较大,先得调整eclipse jvm参数

这里写图片描述
这里写图片描述
哇,一个LinkedBlockingQueue无界队列占jvm94.48%

分析代码看到了,原来是生产者比消费者快的多。导致这样的问题。最后加大了消费者的速度,跟消费者的数量。

以上是我工作上遇到的问题,如果大家发现了问题,可以跟我一起来探讨

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值