Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn more

View all

Sign in to view all badges

SOLVED

Change Parallel GC to G1GC

gunpreets102403
Level 2
Level 2

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.

1 Accepted Solution
aemmarc
Correct answer by
Employee
Employee

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.

View solution in original post

5 Replies
webcoholiccc
Level 2
Level 2

Check the threads , whether they still holding session .

jbrar
Employee
Employee

You can change the garbage collector by using the following in the JVM parameters:

-XX:+UseG1GC

Check [1] for more details.

[1] Configuring the G1GC Garbage Collector for AEM

aemmarc
Correct answer by
Employee
Employee

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.

View solution in original post

SonDang
Employee
Employee

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

jimt82977416
Level 1
Level 1

JVM has provided helpful arguments to deal with OutOfMemoryError.  Those JVM arguments are:

  1. -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath
  2. -XX:OnOutOfMemoryError
  3. -XX:+ExitOnOutOfMemoryError
  4. -XX:+CrashOnOutOfMemoryError

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.