Skip to Content

Here we go, the most important performance consideration for any SAP NetWeaver Java system, especially one of type PI, CE or Portal. Let’s say your system hangs, it crashes, requests are non-responsive, interfaces stall, or monitoring behaves strangely. All of these issues could be caused by completely different things, BUT they can also all be caused by one thing.

Are you ready for me to save you hours and hours of useless debugging?

So if you’re having various, annoyingly strange issues with your Java system, this is the first and most important tip I can recommend for you:

MEMORY!!!


Having sufficient memory is the most important factor for a SAP Java system to function properly. Speaking from experience, a SAP Java system with one central instance, regardless of type, should have at least 16 GB of memory. For each application server that you add to the central instance, another 16 GB. To be on the safe side, I recommend at least 64 GB per application server for production systems.

Depending on the type of activities that go on in your system, and if time allows, it would be best to monitor the usage of memory and then coming up with your own sizing.

The reason SAP Java systems can behave like wailing newborns when not given sufficient memory is all because of one thing: the garbage collection. And I can’t stress enough the importance for garbage collection to function smoothly on SAP. Java systems are recommended by SAP to be allocated 3 to 4 GB of java heap memory. So you may think, like I once did, that the amount of memory you add to the server has no impact on the Java application server.

Although applications running on a Java system utilize only the allocated JVM heap, the garbage collection processes utilize way more than what’s allocated to the JVM. Upon monitoring the memory usage of a Java system, you should see that when garbage collection takes place, the memory usage goes up on the server, surpassing 3 to 4 GB, usually hitting the 16 GB ceiling.

So, there you have it. Put a leash on your SAP java system by increasing memory!

by Founder of the Mediocrity Demolition Project

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Manas Behra

    Hi  Juichia,

    Nice Blog , recently we have issue in BI  java , non of queries were  working , and in logs , it was saying no connection to backend system . as seems connection was not working with backend BI system . but looking in E2E it was hugh GC usage at that time . we have to take restart of server to resolve this issue . But strange phyiscal memory was not exhaused completely and no heap memory dump at that time . we have already suggested for additional memory , but how to  utilize that additional memory so that java should not beahve like before ( hugh GC usage  )  , any other paramter changes which will be helpful in that case  .

    Thanks

    Manas Behra

    (0) 
    1. Juichia Che Post author

      Hello Manas,

      Thanks for reading.

      We experienced high GC and frequent GC as well, and this all went away when memory was increased to sufficient amount. When GC has not enough memory to utilize, it behaves very strangely. I hope the memory fix will resolve your problems.

      Juichia

      (0) 
  2. Dieter Waelkens

    Hi,

    very interesting feedback. Never really thought about it in that way.

    Fact is that you need to avoid swapping as much as possible, and that you can do by adding memory. Definitely with Java systems, since they are – as you mention – very memory dependant.

    Little tip from my side as well 😉 If you experience out-of memory issues though, a memory dump can be of great help. It helps you analyse what exactly occupies the memory used in your Java engine. Because adding memory will probably solve the issues, but not the root cause, so it’s hugely important to find the root cause

    We had a BI Java system installed on a Solaris machine and it was constantly restarting because of out of memory issues. Using this we noticed that a precalculation report was causing this.

    Regards,

    Dieter

    (0) 
    1. Juichia Che Post author

      Hi Dieter,

      Great point! I agree, there needs to be analysis of OOM dumps as well as making sure the memory requirements are met.

      I experienced on a PI Java only system OOM dumps that were caused by the IDoc adapter. Although SAP has improved the java only IDoc adapter’s performance with each new release, it’s still not as optimal as the original ABAP IDoc adapter. This is when we figured out that having sufficient memory eliminated the issue created by the java only IDoc dapter.

      Sometimes SAP standard apps and modules do cause the OOM dumps, but it seems that for java only systems, it’s much more efficient to increase memory, than to wait for SAP to fix the performance of their standard modules.

      (0) 

Leave a Reply