Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
TomCenens
Active Contributor

Introduction

Hello SDN Community

In part III of the blog series I will write about Java VM settings basics for your Java based SAP systems.

In my opinion it's a good idea that all users (functional, technical and developers) have a basic understanding how a Java based SAP system works. Because ABAP is already present for a longer period of time most users have a basic understanding how ABAP works and what a shortdump is for example, for Java based SAP systems I often notice users don't know. Getting the basics out there can help users understand crash situations (some can be caused by bad functional use for example) and give information how to avoid them.

In the previous parts of the blog series I discussed what Java objects are and how the basics of Garbage Collection work:

SAP Java Administration - Troubleshooting part I - java as a programming language

SAP Java Administration - Troubleshooting part II - understanding garbage collection basics

Relation to troubleshooting

The reasons why you have to start troubleshooting can be very diverse, a SAP system is not starting up anymore, the performance is bad or got worse over time, the SAP system is not stable and crashes frequently, a root cause analysis is requested because a crash situation occurred, end-users get annoying pop-ups while SSO (single sign on) is configured and so on.

Why are these VM (virtual machine) settings important? The virtual machine can be seen as the brain of the Java engine, it handles object creation, garbage collection and so on. Ensuring you have the proper settings in place for the VM can avoid crash situations (OutOfMemory), improve performance and stability and so on. Translated to the race application from the previous parts of the blog series it influences how many cars can be on the track at once, how fast the information is displayed (who has the best lap time) and avoid situations where it becomes unclear who can stay on the track to do some more laps and who can't and so on.

Another important reason can be that your virtual machine is not starting up properly when you start your Java based SAP system. It can be related to bad VM (virtual machine) settings, for example, a mismatch in values (initial heap size larger than maximum heap size) or a settings that the VM does not recognize (setting parameter -XX:UnknownParameter which doesn't exist will cause your virtual machine to throw and error and it will prevent your SAP system from starting).

Information is an important factor when you perform troubleshooting, the more information you can gather on an issue or problem, the better chance you have solving it. Some settings influence the level of detail you can get out of the logging of the VM.

SAP recommendations

Recommendations made by SAP for certain platforms, products and versions can be found in SAP notes and on help.sap.com. One of the most important SAP notes (which has lots of related SAP note links in it) is "SAP Note 723909 - Java VM settings for J2EE 6.40/7.0".

The content of this blog is also still valid for SAP Netweaver 7.1 and higher but those versions use zero administration templates. The zero administration template is basically a SCA component in the java stack that contains the recommended settings (thus sets the recommended settings for you). It remains possible to add parameters manually or adjust parameter values.

While the recommended settings are good in many cases, mostly in case you use the standard functionality, it is possible you have the need to change the settings yourself to further improve end-user experience or to avoid crash situations.

As a start point for newly installed java based SAP systems I would definitely recommend you set the VM settings according to SAP recommendations. Keep in mind that there are additional SAP notes for certain products such as BI. You can find those notes in the long list of related SAP notes in SAP Note 723909 which is linked in this blog.

Java VM version

Some settings are only supported by certain version of Java VM's. It is important to follow the recommendations of SAP in this case and ensure you have the correct Java VM version running for your platform. Having the right version eliminates known issues and enables new functionality (settings) to further improve performance, stability etc.

You can find the recommendations for your platform in SAP note 723909 mentioned above under Solution.
Those SAP notes can be recognized by the following text: "notenumber for the platform JDK" will give information on which VM version is the latest recommended version for your platform.

SAP Netweaver 7.0 and lower use the platform JVM (if you Java HP/UX as platform for example you will be using HP's JVM). Higher releases SAP Netweaver 7.1 and higher use SAP JVM (a VM SAP made themselves based on SUN JVM).

Comparison of both on selected topics in following table:

TopicPlatform JVMSAP JVM
Parameter settingsManual settingsZero administration template
Logs readabilityBadBetter
UpdatingRequires stop/start of all SAP system using the same VM on the same serverNo impact on other SAP systems
Bug fix frequencyWhen platform vendor decides to set a new release = not frequentWhen SAP detects an issue or a customer reports an issue = very frequent
Java releaseJava 1.4Java 1.5
DispatchingDispatcher nodeICM (internet communication manager)

Do I still have to state I prefer SAP JVM?


One thing I hoped for which did not yet happen (perhaps foreseen in the near future by SAP) is a possibility to change a SAP Netweaver 7.0 from using the platform JVM to using SAP JVM.


If you have insight or news on this please share it in the comments as I would love to know and I bet others would also love to hear about it.

Architecture

The below links give information on the most simple configuration of a Java based SAP instance, if you don't have an idea how the architecture looks like, I would recommend you read through the documentation.

SAP Netweaver 6.40 / 7.0

Link to documentation on architecture:

Java Cluster architecture

SAP Netweaver 7.1 and higher

Link to documentation on architecture:

Java Cluster architecture

Memory area settings

Heap space

Picture 1.1

This picture should look familiar from part II of the blog series but this time you can see some additional parts, the virtual parts. The virtual parts representst possible growth up to a certain size. In picture 1.1 you can see the heap space (everything inside black square). There are two parameters which are used to determine the heap size.

  • -Xms which sets the initial size of the heap space.
  • -Xmx which sets the maximum size of the heap space.

Example: when you set -Xms1024m and -Xmx2048m it means you start with a heap space of 1024MB and it can grow up to 2048MB.

Some advantages:

  • The allocated ammount of memory when you Java stack start is only 1024MB.
  • If your SAP systems doesn't need more memory, it will not allocate more memory.

Some disadvantages:

  • Startup of your Java stack can be slow if the initial size isn't suffcient and resizing needs to occur already.
  • Application performance will be worse when resizing has to take place, more objects need to moved around.

I say some because there are more arguments but these are enough to say it's recommended to keep both the initial heap size and maxiumum heap size on the same value.

This would mean for our example that setting -Xms2048m and -Xmx2048m is a better to avoid slow startup times and to have better application performance.

Young generation space

Picture 2.1

This picture should look familiar from part II of the blog series but this time you can see some additional parts, the virtual parts. The virtual parts representst possible growth up to a certain size. In picture 2.1 you can see the young generation space (everything in blue). Depending on which platform your java stack resides, the following parameter settings define the young generation space.

IBM platforms

  • -Xmn which sets both the initial size and maximum size of the young generation space.
    • Example: -Xmn1024 sets both initial and maximum size of the young generation space to 1024MB.

Hotspot VM, i.e. Windows, Solaris, HP and Linux (with SUN JDK)

  • -XX:NewSize which sets the initial size of the young generation space.
  • -XX:MaxNewSize which sets both the maximum size of the young generation space.
    • Example: -XX:NewSize=340m and -XX:MaxNewSize=340m sets both initial and maximum size of the young generation space to 340MB.

The same as for the heap space is valid, for your Java stack it's better to set the initial size and maximum size to the same value.

Survirvor space(s)

Picture 3.1

Picture 3.1 is valid for Hotspot VM, i.e. Windows, Solaris, HP and Linux (with SUN JDK)/p>

The parameter survivorratio determines the size of the survivor spaces.

Example: You set the young generation space to 340MB with parameter -XX:NewSize=340m, -XX:MaxNewSize=340m and -XX:SurvivorRatio=2 then one survivor space equals (340MB / 2) / 2 = 85MB for one survivor space.

For IBM platform, there is no parameter to maintain as the size is automatically resized by the java virtual machine to be as performant as possible

Tenured (old generation) space

Picture 4.1

The tenured space size is determined by the heap space size minus the young generation space size (see picture 4.1).

Example:

For a Java stack residing on an IBM platform we set -Xms2048m, -Xmx2048m and -Xmn1024m. This would mean the tenured size is 1024MB, the heap size has a fixed value of 2048MB, from that you subtract the young generation space size which is 1024MB. The leftover is 1024MB which is then the size of the tenured (old generation) space.

Permanent space

Picture 5.1

Picture 5.1 is valid for Hotspot VM, i.e. Windows, Solaris, HP and Linux (with SUN JDK).

  • -XX:PermSize which sets the initial size of the perm (permanent) space.
  • -XX:MaxPermSize which sets both the maximum size of the perm space.
    • Example: -XX:PermSize=1024m and -XX:MaxPermSize=1024m sets both initial and maximum size of the perm space to 1024MB.

The same as for the heap space is valid, for your Java stack it's better to set the initial size and maximum size to the same value.

Conclusion

With the first three parts I wanted to get some basic information accross before diving deeper into troubleshooting.
In the next part I will write about which tools you can use to perform Java troubleshooting.


Having the right settings in place can avoid the need to perform troubleshooting. Reviewing those settings is always a good idea when issues occur to ensure you are working with the right configuration in place.

11 Comments
Labels in this area