IdentityMinder product encounters "GC" resource starvation 4 days after restart, Inquiring about potential product update to remediate this issue
search cancel

IdentityMinder product encounters "GC" resource starvation 4 days after restart, Inquiring about potential product update to remediate this issue

book

Article ID: 218164

calendar_today

Updated On:

Products

CA Identity Suite

Issue/Introduction

Our production IdentityMinder installation always run out of "garbage Collection" resources every 3-4 day after initial restart. Our solution is restarting IDM/JBOSS services every 24 hours, so it would not have a chance starving off resources. We wonder if there are any product update in near future to resolve this issue.

Environment

Release : 14.3

Component : CA IDENTITY SUITE (VIRTUAL APPLIANCE)

Resolution

-verbose:gc -Xloggc:/opt/CA/jboss/standalone/log/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=3M -XX:-TraceClassUnloading -Xms8192m -Xmx8192m -XX:MaxPermSize=256m

Both attached server logs show the same settings.

 

Now, without the GC logs, a very important point to make, is that performance tuning is different per every customer and is up to the customer to tune for thier environment. 

Recommendations from oracle:

When you evaluate and fine-tune G1 GC, keep the following recommendations in mind:

  1. Young Generation Size: Avoid explicitly setting young generation size with the -Xmn option or any or other related option such as -XX:NewRatioFixing the size of the young generation overrides the target pause-time goal.

  2. Pause Time Goals: When you evaluate or tune any garbage collection, there is always a latency versus throughput trade-off. The G1 GC is an incremental garbage collector with uniform pauses, but also more overhead on the application threads. The throughput goal for the G1 GC is 90 percent application time and 10 percent garbage collection time.

 

With these two points come these settings:

Again, this is for your team to research and find the best setting to use in your environment.

The G1GC algorithm, which has been introduced with stable Java 1.7 is doing well. You have to just specify maximum pause time you want to live with in your application. JVM will take care of all other things for you.

Key parameters:

-XX:+UseG1GC -XX:MaxGCPauseMillis=1000 

There are some more parameters to be configured. If you are using 4 GB RAM, configure region size as 4 GB/2048 blocks, which is roughly 2 MB

-XX:G1HeapRegionSize=2  

If you have 8 core CPU, fine tune two more parameters

-XX:ParallelGCThreads=4 -XX:ConcGCThreads=2 

Apart from these parameters, leave other parameters values to default like

-XX:TargetSurvivorRatio etc.

Have a look at oracle website for more details about G1GC.

-XX:G1HeapRegionSize=n

Sets the size of a G1 region. The value will be a power of two and can range from 1MB to 32MB. The goal is to have around 2048 regions based on the minimum Java heap size.

 -XX:MaxGCPauseMillis=200

Sets a target value for desired maximum pause time. The default value is 200 milliseconds. The specified value does not adapt to your heap size.

-XX:ParallelGCThreads=n

Sets the value of the STW worker threads. Sets the value of n to the number of logical processors. The value of n is the same as the number of logical processors up to a value of 8.

If there are more than eight logical processors, sets the value of n to approximately 5/8 of the logical processors. This works in most cases except for larger SPARC systems where the value of n can be approximately 5/16 of the logical processors.

-XX:ConcGCThreads=n