#java #memory-leaks #garbage-collection #jvm #wildfly-8
#java #утечки памяти #сбор мусора #jvm #wildfly-8
Вопрос:
У нас есть корпоративное приложение, развернутое в wildfly 8.2 с минимальной и максимальной кучей, установленной на 1,5 ГБ. Одно из действий приводит к загрузке слишком большого количества объектов в кучу. Хотя объект разыменовывается после действия, использование кучи jvm не снижается.
Но, если я вручную запускаю GC извне (используя jcmd), я вижу огромное падение использования кучи. Почему обычный GC не уменьшает объем памяти так сильно, как GC.run?
Настройки JVM
-Xms1536m -Xmx1536m -XX:MaxMetaspaceSize=512m -XX:ReservedCodeCacheSize=128M -server -XX: HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -подробный:gc -XX: PrintGCTimeStamps -XX: PrintGCDetails -Djsse.enableSNIExtension=false — Dsun.rmi.dgc.client.gcInterval= 600000 -Dsun.rmi.dgc.server.gcInterval= 600000
Ответ №1:
То, что вы запускаете извне, является основным / полным GC, который не запускается автоматически, если в этом нет крайней необходимости. JVM пытается зарабатывать на жизнь мусором в старом поколении как можно дольше, чтобы избежать печально известной паузы GC.
Комментарии:
1. Обратите внимание, что OP уменьшает частоту запуска GDC полного GC, что косвенно способствует такому поведению. 1
2. Хорошо отмечено… но применимо ли это и к EJB? Они должны быть объединены и «очищены» после запроса. Я думал, что DGC — это скорее проблема с использованием raw RMI.
3. gdc предназначен для rmi, но он обеспечивает регулярное выполнение полных GCS, независимо от того, что вы делаете.