#1 Performance Tip for SAP NetWeaver Java
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!
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
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
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
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.
Hello
this is a little controversy I think
you have to calculate JAVA Server Nodes together with available RAM
so if you host a NetWeaver with 64GB RAM you can not increase unlimited Server Nodes, but you should also not run only one or two SAP NetWeaver JAVA Node with default JAVA settings.
my default calculation is JAVA Server Node * 8GB RAM for productive systems and Default SAP JAVA settings. For each Application (OS, JAVA Node, etc.) at least on CPU core must be available too!
Additional RAM must be reserved for OS and each additional Application, If DB is hosted on Single server to, you must reserve RAM for DB too, and so on.
The CPU cores must be included into calculation of available SAP JAVA Nodes (or instances).
a good performing system is running with the minimum on full GC.
If you have more than one full GC on each node in a couple of hours, you need to optimize your system instantly.
If CPU load is to high, there is some optimization (re-calculation) needed, too.
I fully agree with Dieter, that swapping needs to be avoided too. That is including, that enough memory is available, for OS, NetWeaver, additional Applications (e.g. DB) and Virus Scanning for example.
in most of the scenarios the SAP JAVA Default Settings are fine, and you have to increase SAP NetWeaver Node only, according available RAM and CPU cores.
keep also attention of available disk space, because each JAVA Node, is consuming disk space when running. in most cases the disk space is not really a bottle neck.
regards
Matthias