While running my application's performance test, the servers's memory is fully utilized. After the test is completed, memory is not automatically get free.
One of the case i think is i need to change the garbage collector form parallel to G1.
Can anyone guide me how to change the garbage collector in aem and also if you have any other solution of this problem, kindly write it down.
Solved! Go to Solution.
Changing the GC algorithm isn't going to fix your memory issue.
Run AEM with the flag : XX:+PrintGCDetails
which will write the garbage collection logs to disk, then upload those logs into a tool like GCEasy (Universal JVM GC analyzer - Java Garbage collection log analysis made easy )
This will give you a visualization of the heap state over time. When garbage collection is an issue you'll see many red-triangles in CGEasy which indicates that FullGC is being run consecutively and throttling the AEM java process.
Then capture an HPROF when the heap is fully utilized and open that HPROF using the Eclipse Memory Analyzer tool (Eclipse Memory Analyzer Open Source Project | The Eclipse Foundation )
Use Eclipse MAT to find the Leak Suspects and review the Dominator tree to see what are the large objects in memory.
Then fix your code.
Check the threads , whether they still holding session .
You can change the garbage collector by using the following in the JVM parameters:
-XX:+UseG1GC
Check [1] for more details.
Views
Replies
Total Likes
Changing the GC algorithm isn't going to fix your memory issue.
Run AEM with the flag : XX:+PrintGCDetails
which will write the garbage collection logs to disk, then upload those logs into a tool like GCEasy (Universal JVM GC analyzer - Java Garbage collection log analysis made easy )
This will give you a visualization of the heap state over time. When garbage collection is an issue you'll see many red-triangles in CGEasy which indicates that FullGC is being run consecutively and throttling the AEM java process.
Then capture an HPROF when the heap is fully utilized and open that HPROF using the Eclipse Memory Analyzer tool (Eclipse Memory Analyzer Open Source Project | The Eclipse Foundation )
Use Eclipse MAT to find the Leak Suspects and review the Dominator tree to see what are the large objects in memory.
Then fix your code.
I completely agree with this assessment. I strongly suspect there is a memory leak happening.
I would recommend using less memory and run your tests until you hit an OOM error. Make sure you have the appropriate JVM parameters (below) to capture the heap dump when the OOM error occurs. Then analyze at mentioned by the previous post.
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/folder/to/store/heapdump
JVM has provided helpful arguments to deal with OutOfMemoryError. Those JVM arguments are:
In order to diagnose OutOfMemoryError or any memory related problem, one would have to capture heap dump right at the moment or few moments before the application starts to experience OutOfMemoryError. It’s hard to do capture heap dump at the right moment manually because we will not know when OutOfMemoryError is going to be thrown. However, capturing heap dumps can be automated by passing following JVM arguments when you launch the application in the command line:
-XX:+HeapDumpOnOutOfMemoryError and -XX:HeapDumpPath={HEAP-DUMP-FILE-PATH}
Example:
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/crashes/my-heap-dump.hprof
In ‘-XX:HeapDumpPath’ you need to specify the filepath where heap dump should be stored.
When you pass these two JVM arguments, heap dumps will be automatically captured and written to a specified file path, when OutOfMemoryError is thrown.
Once heap dumps are captured, you can use tools like HeapHero, Eclipse MAT to analyze heap dumps.
Views
Replies
Total Likes
Views
Likes
Replies