现在的位置: 首页 > 编程语言 > 正文

java 内存溢出问题该如何检查

2020年02月24日 编程语言 ⁄ 共 2565字 ⁄ 字号 评论关闭

  工作中遇到的java 内存溢出问题,我们改如何进行排查和解决呢。

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

  CentOS release 6.4 (Final)

  MemTotal: 16333916 kB

  Intel(R) Xeon(R) CPU E7-4860 v2 @ 2.60GHz 8C

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

抱歉!评论已关闭.