NW 7.1 J2EE performance - long running garbage collection

[george_hamilton]

Hello,

I'm running into a situation on my J2EE engine where the garbage collection is running high. It's around 11-13 seconds, with a full GC. There is no swapping, and the CPU time for the GC matches the time taken for the GC. I only have one server node.

J2EE 7.1 has the zero administration templates which tell you not to make any changes unless carefully calculated. There are the equations in the configtool that set the parameters. The problem is, I need to figure out the problem.

I have changed the heap size to 2GB from the setting on the system of 1GB. The system has 16GB of memory with 8 CPUs.

What's even more strange is that this full GC continues when there is no load on the system at all. When the system is restarted the GC is normal (.01 seconds or so). I would think the GC would go back to .01 seconds (or around there), when message traffic stopped.

Is there some reason in Process Integration that this is normal? SAP documentation seems to indicate a memory leak or that I need to add a server node. The other options about swapping on the server, etc., are not occuring. That is, there is no swapping.

Question: In this case does increasing the heap size myself (ignore the zero administration recommendations), help or does it make it worse by making the GC longer?

Why does the GC take just as long when there is hardly any message traffic going through?

Any help is greatly appreciated as I am baffled by this.

[former_member413439]

Hello George,

I'm facing the same scenario. Which recommendation worked fine for you? JVM actualization?

Thanks,

[george_hamilton]

sorry it took so long to post again. I went from JVM 5.15 to JVM 5.56. That didn't help with the GC, but it did help with a high volume crash issue I was having. Use notes 1442124, 1133020, and 1434916 to help you out. I deployed the JVM instead of doing it manually.

I increased my Heap to 4GB. That helped with a crash I was getting with server out of memory because of a message size problem. I'm going to try adding another server node in my sandbox and see how that plays out.

What's interesting is that in the MMC I see a lot of "small gc" with short times. But, if I go into the default trace files, I see GC of .12. I guess that is showing the delta. I guess the .2 GC is okay then?

[Former Member]

Hi George,

Did you add another server node?

That won't address your GC performance issues but the second node may allow users to still get stuff done while GC is out chasing its tail.

WL

[george_hamilton]

No. I'm going to add more heap memory in the mean time. If I add a server node, can I delete it later? I'm a little nervous about adding things like a server node. How involved is that? If you are on PI 7.1, does it inherit the values from the template?

[Former Member]

George,

Adding a server node would increase performance, but you would need more memory (RAM) on your server.

You can delete the server node at any time and then restart your J2EE Engine.

Kindly note that additional server node also slows the startup process of the J2EE Engine, but would increase the performance in a long run, provided you have enough Memory on your server.

Thanks,

Haleem

[Former Member]

Hi George,

Please take note of section 5.2 Survival Space of note 723909:

and make sure that -XX:SurvivorRatio is set to 2.

In addition, make sure that you are using the +UseParNewGC option,

it will accelerate the gc's.

And take care of your NewSize and MaxNewSize ratios (1/6 of heap)

and permsize and maxpermsize (1/4 of heap)

Regards,

Shimon Zafrir

SAP AGS

[TomCenens]

Dear George

You could take a look in the MMC console by going to http://<FQDN>:5<instance no>13 and take a look at the J2EE memory monitoring there.

Another good monitoring tool is WIly Introscope which can be useful for situations such as this one. Solution Manager diagnostics can also give KPI (key performance indicators) and the combination of above tools can generate Java EWA reports which state performance indicators and give valuable information.

For sure if you haven't yet patched the SAP JVM, please do so as patches are released frequently it can be a solution to the issue. The zero administration template is also frequently updated and those are also available on SAP service marketplace.

I wouldn't take the zero administration as the best possible value, it depends on the load / use of the SAP system. Yes in many cases the zero administration template will do fine but it's not a problem to customize parameters if needed.

Increasing the heap size will result in longer GC time when a full GC occurs but it can prevent full GC's from occuring more often.

How often do the full GC's occur and what's there ratio compared to minor GC's ?

A GC time of 11 - 13 seconds is not by definition an issue, it depends on how often they occur.

Kind regards

Tom

[Former Member]

Hi my friend

I had a similar issue earlier, and 71x release Java is not like 70x that there are a lot of optimization effort could do for JVM parameters. I would suggest to apply the latest SAPJVM5.SAR, my performance issue was somehow resolved by the latest patch. If it doesn't help, then let's do fine tuning in configtool.

Regards,

[Former Member]

Hello Fan,

I am also facing the same issue. You have mentioned the following points

 I would suggest to apply the latest SAPJVM5.SAR, my performance issue was somehow resolved by the latest patch.

Where can I find SAPJVM5.SAR patch? I tried searching sap.service.com/swdc, but could not find this patch.

 If it doesn't help, then let's do fine tuning in configtool 

What is the fine tuning recommended in configtool, to resolve this long running Java garbage collection?

Thanks,

Imran

[Former Member]

http://service.sap.com/swdc --> Support Packages and Patches - Entry by Application Group" SAP NetWeaver" SAP NETWEAVER" SAP NETWEAVER PI 7.1" Eintrag nach Komponente" Application Server Java --> SAP JVM 5.1 --> Choose your OS type