OOM Exception с Nashorn после очистки памяти G1G C - PullRequest
Новая
       120

OOM Exception с Nashorn после очистки памяти G1G C

0 голосов
/ 28 апреля 2020

У меня есть веб-приложение, которое работает в следующих настройках среды / G C:

  1. openjdk версия "11.0.6" 2020-01-14 LTS
  2. Tomcat 9
  3. -Xms2048M -Xmx6144M -XX: + UseG1G C -XX: ReservedCodeCacheSize = 64M -XX: + UseStringDeduplication -XX: SoftRefLRUPolicyMSPerMB = 10
* 1010 использование Nashorn, которое, как я знаю, создает большую нагрузку на память, поскольку создает множество SoftReferences для оптимизации истории PropertyMap. В настоящее время мое приложение получает исключение OOM (Java Размер кучи исчерпан) несколько раз в неделю, и я не могу понять, почему. По словам G C Logs и Heap Dump все вроде нормально.

Дамп кучи из OOM показывает много мягких / слабых ссылок, но если я вызову G C на Дампе в JProfiler или Eclipse Memory Analyzer, оба уменьшат дамп с почти 6 ГБ до 500 МБ. Также в настоящее время нет потоков, выделяющих большие объемы памяти.

G C Журналы показывают похожую картину. Куча растет в течение всего дня, в основном в SoftReferences, и как только она достигает 6 ГБ, он делает полный G C, полный G C очищает почти все, но я все еще получаю OOM через 1-2 минуты.

Я предполагаю, что очистка всей кучи занимает больше времени (почти 2 секунды в соответствии с G C Log), и в это время появляется OOM. Но я не понимаю, как это возможно. Разве Full G C не должен «остановить мир»? Я попытался XX: SoftRefLRUPolicyMSPerMB = 10, чтобы сократить время ожидания SoftReferences, но это не помогло. Почему ссылки накапливаются за весь день?

Я загрузил здесь журналы G C, если кому-то нужен обзор: Анализ GCEasy

Вот G C Журнал полного G C и что также странно: прогон 1175, который был отменен через 1 минуту: 

[38014.682s][info   ][gc,task       ] GC(1179) Using 4 workers of 4 for full compaction
[38014.682s][info   ][gc,start      ] GC(1179) Pause Full (G1 Humongous Allocation)
[38014.709s][info   ][gc,phases,start] GC(1179) Phase 1: Mark live objects
[38015.462s][info   ][gc,stringtable ] GC(1179) Cleaned string and symbol table, strings: 269648 processed, 116742 removed, symbols: 768892 processed, 127 removed
[38015.462s][info   ][gc,phases      ] GC(1179) Phase 1: Mark live objects 753.351ms
[38015.462s][info   ][gc,phases,start] GC(1179) Phase 2: Prepare for compaction
[38015.543s][info   ][gc,phases      ] GC(1179) Phase 2: Prepare for compaction 81.292ms
[38015.543s][info   ][gc,phases,start] GC(1179) Phase 3: Adjust pointers
[38015.725s][info   ][gc,phases      ] GC(1179) Phase 3: Adjust pointers 182.121ms
[38015.726s][info   ][gc,phases,start] GC(1179) Phase 4: Compact heap
[38015.828s][info   ][gc,phases      ] GC(1179) Phase 4: Compact heap 102.293ms
[38016.550s][info   ][gc,heap        ] GC(1179) Eden regions: 0->0(389)
[38016.550s][info   ][gc,heap        ] GC(1179) Survivor regions: 5->0(20)
[38016.550s][info   ][gc,heap        ] GC(1179) Old regions: 2949->255
[38016.550s][info   ][gc,heap        ] GC(1179) Humongous regions: 106->40
[38016.550s][info   ][gc,metaspace   ] GC(1179) Metaspace: 947300K->289843K(2306048K)
[38016.550s][info   ][gc             ] GC(1179) Pause Full (G1 Humongous Allocation) 6119M->579M(2048M) 1868.032ms
[38016.550s][info   ][gc,cpu         ] GC(1179) User=3.97s Sys=0.05s Real=1.86s
[38016.550s][info   ][gc,marking     ] GC(1175) Concurrent Mark From Roots 61386.527ms
[38016.550s][info   ][gc,marking     ] GC(1175) Concurrent Mark Abort
[38016.550s][info   ][gc,stringdedup ] Concurrent String Deduplication (38016.550s)
[38016.550s][info   ][gc             ] GC(1175) Concurrent Cycle 61403.148ms

Я надеюсь, что кто-то может указать мне правильное направление, в чем проблема и в чем Я могу с этим поделать.

С уважением.

...