Question Re: Full Grabage Collection Problem in Technology Q&A

Full Grabage Collection Problem

former_member184114 — Mon, 19 Dec 2011 08:58:03 GMT

Hi All,

I was getting a "RED" EWA report sometime back for Full Garbage collection for one of our JAVA only AS. I increased the JAVA heap memory for all the server nodes (I have 3 server nodes) from 1024MB to 3072MG. After that, the problem got solved and I was getting normal report and there was not full garbage collection problem.

However, from past 4 weeks, I have been getting the same full garbage collection. I looked into the std_server<no> files and found that, std_server0 has more number for full garbage collection recording than other two. However, I dont know what to do next in this regard. Should I again increase the heamp memory for all the nodes? If so, then what should I do if again I get this problem in future? If not, then how can I diagnose this and troubleshoot?

Please guide.

Regards,

Faisal

Re: Full Grabage Collection Problem

nicholas_chang — Mon, 19 Dec 2011 11:38:39 GMT

Hi Faisal Khan,

First of all, is your JVM set according to SAP Note Note 723909 - Java VM settings for J2EE 6.40/7.0 and etc?

FYI, Garbage Collections occur when the Tenured generation fills up, that's Objects that are old enough (as determined by the JVM) get copied from the Young generation to the Tenured generation during Minor GCu2019s, and when the tenured fills up, the dead object (garbage) get swept. Normally full GC take much longer than minor GC due to the size in Tenured are much bigger than Eden.

Instead of increasing the memory blindly, you need to find out the root cause, such as memory leak, high memory consumption by certain thread and etc..

Please ensure below parameters are added:

-verbose:gc

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

View the log \sysID\instID\ work\std_server0.out> and search for the Full GC. From there, you can see how often Full GC happens, what's the duration and etc.

Java memory analysis and troubleshooting is not a easy topic. You can search more info on SDN or SMP and look for Java Analysis tool.

Is your system performance impact due to high frequency of Full GC?

Hope you find those information useful.

Cheers,

Nicholas Chang

Re: Full Grabage Collection Problem

blanca_serrano — Mon, 19 Dec 2011 14:42:56 GMT

Hello Faisal,

I totally agree with Nicholas, but I also want to suggest you to create another server node, this will help to reduce full GC time and will increase the performance.

I hope this helps you.

Regards,

Blanca

Re: Full Grabage Collection Problem

Former Member — Mon, 19 Dec 2011 19:19:04 GMT

Faisal,

The garbage collection frequency and duration are all relative, and therefore it is hard to give you a sound advise without a specific case.

The duration of full garbage collection is impacted by hardware, memory speed, and the amount of memory configured.

Thus if your heap space is 2GB, you will have shorter but more frequent GC, than if your memory is 3 GB. In the former case you will have lass frequent but longer full GC.

Before you change your memory configuration, or add server nodes, could you please share how frequent and long are the garbage collections on your system?

What is the usage type of your system?

Best,

Ventsi Tsachev

Re: Full Grabage Collection Problem

former_member184114 — Tue, 20 Dec 2011 06:33:29 GMT

Hi Ventsi,

Thanks for your kind reply.

I looked into std_server0.std file and it was modified last today (12/20/2011). I searched for "Full Garbage" and noticed that, it occurred 43 times. However, I think this is accumulated over a period of time and this will was started from 12/03/2011. Therefore, I am unable to tell you how many times it occurred in today's date. Please let me know how I can determine the same on a specific date.

Please suggest.

Regards,

Faisal

Re: Full Grabage Collection Problem

former_member184114 — Tue, 20 Dec 2011 06:38:53 GMT

Hi Nicholas,

Thanks for your reply.

yes, my server is set/configured according to the note mentioned by you. And the other parameters you mentioned are also availabe for each server node.

As i just mentioned, it occurred 43 times in std_server0.out file which was created on 12/03/2011. This was updated on today's date last.

Please guide me in diagnosing the problem.

Regards,

Faisal

Re: Full Grabage Collection Problem

nicholas_chang — Tue, 20 Dec 2011 07:54:06 GMT

Hi Faisal,

FYI, if the last update was on 12/03/2011, it could be the last Full GC (43rd GC) happened on this day. You can use SAP Memory Analyzer to perform java memory analysis or you'll get a nice graphic on Java memory usage if you have installed and utilize the RCA/E2E in Solman.

However, i suggest you to standardize your 3 server nodes to 2GB, and add another one or two if you physical memory allows.

Cheers,

Nicholas Chang

Re: Full Grabage Collection Problem

former_member184114 — Tue, 20 Dec 2011 10:37:25 GMT

Hi Nicholas,

Thanks for the reply.

I went to RCA->E2E Analysis->JAVA memory Usage. The period I selected is from 12/12/2011 until 12/19/2011. I got the below details:

Metric Name Average                                              Value 
   % GC TIME (LAST 5 MINUTES)                                            0 
   ALLOCATION RATE (BYTES PER S)                                 2.831 
   EFFECTIVE OLD SPACE USAGE (%)                                   28 
   FULLGC FRACTION (%)                                                        1 
   OLD SPACE GROWTH (BYTES PER S)                                -1 
   PROMOTION RATE (BYTES PER S)                                       0

May you please help me understand t his? Specially, the Full GC Fraction(%). It says, 1. Does it mean that it took place just once for me period of selection?

Regards,

Faisal

Re: Full Grabage Collection Problem

nicholas_chang — Tue, 20 Dec 2011 15:35:04 GMT

Hi Faisal,

Is been a long time since i worked on E2E and the information provided is not detailed.

Perhaps you can download the guide from https://websmp105.sap-ag.de/diagnostics and i think it'll be helpful for you.

Cheers,

Thanks,

Nicholas Chang