Как решить Metaspace OOM после многократного повторного развертывания веб-приложения в Tomcat? - PullRequest
3 голосов
/ 14 июня 2019

Dera all,

Я использую openjdk 1.8.0_212-b04, Tomcat 8.0.21 и Red Hat 6.4.

И я настроил тестовое веб-приложение, убедитесь, что оно будетбыть нет такого сообщения после его повторного развертывания:

WARNING: The web application [Test] appears to have started a thread named [test-job_Worker-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread

Вот параметр GC, который я использовал в тесте:

-Xms2G -Xmx4G 
-XX:MaxMetaspaceSize=1G -XX:CompressedClassSpaceSize=300 

-Dsun.rmi.dgc.client.gcInterval=9223372036854775807 
-Dsun.rmi.dgc.server.gcInterval=9223372036854775807 
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:GCLogFile Size=10M -XX:NumberOfGCLogFiles=5 -Xloggc:$LOG_HOME/gc-$START_TIME.log

И я использовал сценарий оболочки, продолжайте прикасаться к web.xml для повторного развертывания веб-приложения.Во время теста не было никаких других операций / операций.

Вот график метапространства VisualVM во время теста: enter image description here

Как показано на рисунке: в точке1, метапространство будет уменьшаться в какое-то время, поэтому я думаю, что не должно быть утечки памяти в метапространстве.

Но в точке 2 Tomcat выбрасывает мета-пространство OOM:

14-Jun-2019 09:26:32.184 SEVERE [ContainerBackgroundProcessor[StandardEngine[Catalina]]] org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run Unexpected death of background thread ContainerBackgroundProcessor[StandardEngine[Catalina]]
 java.lang.OutOfMemoryError: Metaspace
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2472)
        at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:854)
        at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1274)
        at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1157)
        at org.apache.logging.log4j.status.StatusLogger.<init>(StatusLogger.java:108)
        at org.apache.logging.log4j.status.StatusLogger.<clinit>(StatusLogger.java:85)
        at org.apache.logging.log4j.web.Log4jServletContextListener.<clinit>(Log4jServletContextListener.java:44)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

В точке 3 я нажимал кнопку GC в VisualVM, мета-пространство фактически сокращалось.

Я попытался добавить параметр: -XX: MaxMetaspaceFreeRatio = 60, но все еще получил результат smae.

Вот график метасмеси GCeasy: enter image description here

Вот журнал GC: * ​​1034 * Журнал GC

Спасибо за любые советы по устранению / устранению / отладке ошибки OOM.

Обновление 1: Спасибопо предложению @ samabcde я добавил se.jiderhamn.classloader.leak.prevention.ClassLoaderLeakPreventor, чтобы сделать больше тестов.Это помогает удалить некоторые переменные ThreadLocal и сделать веб-приложение более длительным.

14-Jun-2019 17:44:31.463 INFO [ContainerBackgroundProcessor[StandardEngine[Catalina]]] se.jiderhamn.classloader.leak.prevention.JULLogger.info Custom ThreadLocal of type org.springframework.core.NamedThreadLocal: Prototype beans currently in creation with value null will be remove()d from Thread[ContainerBackgroundProcessor[StandardEngine[Catalina]],5,main]

Но все же получил OOM для Metaspace.enter image description here

1 Ответ

3 голосов
/ 15 июня 2019

Во время теста я увидел, что Metaspace почти достиг максимума, затем остановился для повторного развертывания веб-приложения и сделал дамп кучи, поместив его в MAT для анализа.

Как и следовало ожидать, есть много WebappClassLoader. Но я проверил, что это Путь к корням GC | исключить все фатом / слабый / мягкий. и т.д. ссылки , это GC Root.

Я проверил, что это Путь к корням GC | со всеми ссылками , то есть более одного корня GC. enter image description here

Итак ... эти WebappClassLoader на самом деле являются phatom / weak / soft на которые ссылаются другие объекты, он будет оставаться в куче некоторое время, чтобы быть освобожденным.

Затем я добавляю параметр GC: -XX: SoftRefLRUPolicyMSPerMB = 10, веб-приложение может быть повторно развернуто более 1000 раз ...

Итак, проблема решена!

PS. поскольку мы не будем повторно развертывать веб-приложение в производственной среде в течение короткого времени, мы не будем использовать -XX: SoftRefLRUPolicyMSPerMB = 10.

...