SAP EP – Netweaver Portal

Symptom
This note describes recommended JVM settings for standard SAP java applications, for example EP, XI, CRM, etc., running on SAP J2EE Engine 6.40/7.0. For 7.1 please refer to Note 1248926.
Other terms
tuning memory j2ee portal
OutOfMemoryError OOM out of memory
Out of swap space
Reason and Prerequisites
j2ee
Solution
The information in this note is relevant if you don’t use the configuration template (see note 739788) or if you want to manually configure your java stack installation.
Configuration templates are only applicable to newly installed systems based on the J2EE Engine 6.40 SP7 (corresponds to NetWeaver’04 SP Stack 04) or above.
For all other systems you have to configure JVM settings as described below.
Before starting manual configuration please read the following notes:
716604 for the Sun JDK (Windows, Linux, Solaris)
716926 for the HP JDK (HP-UX)
716927 for the IBM JDK (AIX)
1234382 for the IBM JDK IT4J (IBM i, iSeries, OS/400)
717376 for the IBM JDK Classic (IBM i, iSeries, OS/400)
1319038 for the IBM JDK J9 (Linux for zSeries)
746299 for the IBM JDK Sovereign (Linux for zSeries)
810008 for the IBM JDK (Linux on POWER)
861215 for the IBM JDK (Linux on AMD64/EM64T)
NB: Note 709140 is obsolete!
Note 722520 was removed from the list above because the Java stack
is not supported on Tru64 (see note 872554).
Since some of the above notes only take into account the “default” SAP J2EE developer installation some parameters must be set differently for an production systems.
If there are conflicts between parameters recommended in the platform specific notes and the general recommendations below the platform specific recommendations have precedence.
The java parameters have to be set via ConfigTool, see note 710146.
Remark: for adjusting of the SDM Heap see note 879377.
1. Java version
It should be the most actual one from the 1.4 family. J2EE Engine 6.40/7.0 is not supported on 1.3 or 1.5 Java plattform.
Details on the currently recommended versions and how to get them can be found in the above OS-specific notes.

Refer to note 718901 about changing of the JDK, see also 731269.
Please apply note 754699 after JDK upgrade.

The following heap size recommendation is not valid for IBM eServer System i. Follow SAP notes 717376 or 1234382 respectively only on that platform.

2. Heap size
2.1 For 32 bit platforms we recommend to start the server nodes with 1GB whereby the initial and the maximal heap size should be equal: -Xmx1024m -Xms1024m
Higher values may cause troubles, for example see notes 736462 and 664607 about Windows DLLs preventing big java heap.
We recommend using additional server nodes instead of huge heaps.
For 64 bit platforms (that means not only your OS but also your JDK supports 64 bit) we recommend using 2GB: -Xmx2048m -Xms2048m
Take into account while planning your productive landscape: for NW 7.0 (04s) there is a general recommendation to use 64bit systems, see note 996600.
2.2 For dispatcher nodes it’s sufficient to set the heap size to 171m on 32 bit and to 256m on 64 bit platforms. There is no need to apply the parameters mentioned under 4-9 below.
Default size of the young generation (one third of the heap) is ok for dispatchers.
If the instance contains more than three server nodes we recommend to add 50MB of dispatcher heap for each additional server node.
2.3 The max heap size (plus max perm size) of all Java server nodes must fit completely into the physical memory in order to avoid heavy paging on OS level. You must also consider the space needed for OS and other processes.
For each JavaVM on the server, all Java memory must fit completely into physical memory (no paging)!
Therefore the rule of thumb for number of server nodes for SUN and HP JavaVM with 1 GB Heap each will be
#ServerNodes = (AvailableMemory / 1.5 GB)
and factor 2.5 should be used instead of 1.5 for 64 bit with 2GB heap size.
3. Verbose GC
Please always use -verbose:gc option for server and dispatcher.
The below paragraphs 4-9 only apply for HotSpot VM, i.e. Windows, Solaris, HP and Linux (with SUN JDK) but not for IBM platforms
Special remark for AIX: please refer to Note 716927 for advanced tuning of EP and XI.
4. Client or Server VM?
We recommend using Server VM, it’s default in most cases.
Since the Client VM is not available for some platforms (usually a 64-bit VM only has the Server variant) we can’t switch to the Client VM as it was recommended for EP6 SP2 running on JDK 1.3.1.
The Server VM crashes should be reported to the VM provider (SUN or HP) and investigated. In some cases they can be avoided by excluding some classes from compilation (e.g. note 716926). For this purpose we recommend -XX:+PrintCompilation flag.
Remark 1: please don’t use “-server” or “-client” command line parameters, SAP J2EE Startup Framework doesn’t accept them. The VM type should be set by the entry jstartup/vm/type in the instance profile, e.g. jstartup/vm/type=server, if necessary.
Remark 2: R/3 profile maintenance transaction is not aware about above jstartup/vm/type parameter, therefore you have to add it manually.
Remark 3: You don’t really need to select Server VM explicitly because SAP J2EE Startup Framework loads it by default. This option is not for the Java VM itself but for java launcher (e.g. java.exe or Startup Framework) that decides which jvm.dll (or libjvm.so) should be loaded. Server VM is the default choice for java launcher on almost all plattforms with some exceptions like 32-bit Windows, and on some plattforms it is the only available choice. Anyway, Startup Framework loads Server VM by default unless instance profile entry jstartup/vm/type is set to a different type. Compare with note 722520 about True64 where the above profile entry should be set to fast64.
5. New Generation
5.1 NewSize
As before (compare to note 696410) we recommend setting both NewSize and MaxNewSize to approximately 1/6 of the heap, for example
-XX:NewSize=171m -XX:MaxNewSize=171m for 1 GB heap size and
-XX:NewSize=341m -XX:MaxNewSize=341m for 2 GB heap site
5.2 Survival Space
We recommend -XX:SurvivorRatio=2 -XX:TargetSurvivorRatio=90
The first options controls how big is eden space compared to survivor space (the latter contains two semispaces); the second option sets the desired percentage of the survivor space heap which must be used before objects are promoted to the old generation.
6. Permanent Space
For 6.40 on 32 bit: -XX:MaxPermSize=192m -XX:PermSize=192m
For 6.40 on 64 bit: -XX:MaxPermSize=384m -XX:PermSize=384m
For 7.0 on 32 bit: -XX:MaxPermSize=256m -XX:PermSize=256m
For 7.0 on 64 bit: -XX:MaxPermSize=512m -XX:PermSize=512m
Remark 1: Be aware of the fact that more permanent space is needed if additional applications are deployed or the complexity of the applications (roughly speaking number of classes) grows.
Remark 2: increasing of the heap size or permanent space is harmless on 64 bit systems (given that enough physical memory is available, see paragraph 2.3 above) however on 32 bit ones (especially Windows) one should take into account limitations of the virtual address space, see notes 664607 and 736462.
7. Garbage Collector options
7.1 Parallel minor GC
JDK 1.4 contains several implementations of the garbage collector.
We recommend -XX:+UseParNewGC option. It parallelize (and thefore accelerates) minor GCs.
7.2 Other non-standard GC options
We still do NOT recommend -XX:+UseConcMarkSweepGC (it caused VM crashes in earlier JDK 1.4.2 versions) but we’re re-evauating it now based on most actual JDKs.
Because triggering GCs explicitly by Java applications could harm server performance significantly we recommend to set -XX:+DisableExplicitGC in order to ignore such calls.
7.3 GC utility options
a. Please set also -XX:+PrintGCTimeStamps (available since JDK 1.4).
b. -XX:+PrintGCDetails is very useful and doesn’t have any negative effect, therefore highly recommended.
c. In problem case you might be asked to use also the following option:
-XX:+PrintTenuringDistribution
d. Option -XX:+PrintCompilation shouldn’t be used by default (because it produces much output and makes logs less readable), but only in case of troubles with JustInTimeCompiler (JIT).
7.4 Thread local allocation
We recommend -XX:+UseTLAB option which switches on thread local allocation of objects. On Solaris and HP-UX you don’t need to specify this switch explicitly (it’s used by default) but it doesn’t harm also if you set it. On Windows and Linux you have to do this explicitly.
7.5 Workaround for SUN bugs 6206427 and 6226790 which are not fixed in JDK 1.4.2 family
Upgrade your JDK to 1.4.2_12 (or higher) and use the following additional option together with -XX:+UseParNewGC:
-XX:+HandlePromotionFailure
This should help against crashes like
[GC 327539.115: [ParNew
Exception java.lang.OutOfMemoryError: requested 85287040 bytes for promotion. Out of swap space?
7.6 -XX:+PrintClassHistogram is useful for memory problem analysis (be aware that on HPUX it works properly starting with 1.4.2_10).
7.7 Using full Heap dump feature for analysis of memory problems:
this is an even more powerful feature, refer to note 1004255 for more details.
Remark on -XX:+PrintClassHistogram and -XX:+HeapDumpOnCtrlBreak:
be aware that both options use thread dump event to trigger some additional activity. First of all, both of them trigger Full GC. Second, it takes some time to dump the histogram table and the entire heap. Therefore thread dumps shouldn’t be made too often if one of the above options is used. For example scheduling thread dump every two seconds will make your system fully busy with itself and inavailable just because it executes Full GC every time.
8. SoftReferences
-XX:SoftRefLRUPolicyMSPerMB=1 is still recommended
9. JIT Compiler Code Cache
In order to avoid a memory shortage of the JIT compiler code cache following values are recommended:
-XX:ReservedCodeCacheSize=64M
-XX:CodeCacheMinimumFreeSpace=2M
10. System Properties
Remark: If not stated otherwise the following settings are valid for servers on all platforms.
10.1 Disable canonicalization optimization
When using Knowledge Management the setting -Dsun.io.useCanonCaches=false
is required to guarantee functional correctness of CM repositories and file system repositories with file system persistence. This setting is necessary for Windows, HP-UX, Solaris and Linux platforms using the Hotspot VM.
10.2 Thumbnail generation on Linux and UNIX platforms
Image generation for JSP and servlet applications on Linux, Solaris, AIX and HP-UX must run in a “headless” environment – that is, on a computer that lacks framebuffer hardware. This is not needed (but doesn’t harm if set) for Windows.
Headless mode must explicitly be enabled as follows:
-Djava.awt.headless=true
10.3 Security settings
The right security policy has to be set with -Djava.security.policy=./java.policy (on dispatcher too).
The source of seed data for SecureRandom, which provides a cryptographically strong pseudo-random number generator is set with -Djava.security.egd=file:/dev/urandom (except AS/400).
10.4 jARM Monitoring
With -Djco.jarm=1 jARM monitoring for the SAP Java Connector is turned on.
10.5 CORBA settings
Following properties have to be set:
-Dorg.omg.CORBA.ORBClass=com.sap.engine.system.ORBProxy
-Dorg.omg.CORBA.ORBSingletonClass=com.sap.engine.system.ORBSingletonProxy
-Dorg.omg.PortableInterceptor.ORBInitializerClass.com.sap.engine.services.ts.jts.ots.PortableInterceptor.JTSInitializer
-Djavax.rmi.CORBA.PortableRemoteObjectClass=com.sap.engine.system.PortableRemoteObjectProxy
Note that the ORBInitializerClass is specified with a “.” and not with a “=” symbol as the rest of the properties. This is according to the CORBA specification.