0

We moved from Jboss AS 7.1.1 to wildfly 8.2.0 Final. After upgrade, we are seeing full frequent garbage collection on running 60 user load test. Full gc were not able to recover any memory. On analysis we found that org.apache.jasper.runtime.BodyContentImpl is having 1 gb of retained heap. We found root cause in PerThreadTagHandlerPool.java . Patched TagHandelrPool diff --git a/src/main/java/org/apache/jasper/runtime/TagHandlerPool.java b/src/main/java/org/apache/jasper/runtime/TagHandlerPool.java index eaa8560..c6c785f 100644

--- a/src/main/java/org/apache/jasper/runtime/TagHandlerPool.java
+++ b/src/main/java/org/apache/jasper/runtime/TagHandlerPool.java
@@ -53,7 +53,7 @@ public class TagHandlerPool {
                 result = null;
             }
         }
-        if( result==null ) result=new PerThreadTagHandlerPool();
+        if( result==null ) result=new TagHandlerPool();
         result.init(config);

         return result;

This fixed memory leak issue, however we are seeing full frequent gc's every 2 mins when running load test. Full gc is able to recover memory. On analyzing heap dump found most of the heap area is remainder(350 MB) in Eclipse MAT , io.undertow.server.session.InMemorySessionManager occupies around 17 MB and org.hibernate.internal.SessionFactoryImpl occupies around 17.5MB

Tried multiple options 1. Ourmax heap is 1536m, decreased to 1024m and increased to 2048m and 4096m. No benefits 2. Change XX:NewRatio to 3, but no help.

Appreciate your inputs.

Srivathsan
  • 49
  • 1
  • 7
  • 350M is way less than 1536M max heap, wouldn't call it "most". What's the rest? I would chart the heap use in time with gc marks, often this is quite helpful. Trying to estimate average heap increase per transaction is another interesting piece of information. – Alex Nevidomsky May 04 '15 at 18:05
  • While taking heapdump I used jmap -dump:live,format=b,file= . Only took live objects , I don't know I missed remaining heap due to that. May be I should take both live and dead objects. I will let you know heap split-up after that. May be dead objects can help in identifying object cycling. – Srivathsan May 05 '15 at 06:09
  • It seems that remaining 900 MB is grabage that got created. Jmap forces full gc so the garbage is gone when we analyzed heap dumps. Dynatrace leak analysis figured 800 MB as garbage and this will be cleaned up in next GC cycle. We don't know what is inside garbage and why this much garbage is getting created. – Srivathsan May 06 '15 at 07:43

0 Answers0