Proven Practice IBM Cognos ReportNet and the Java Heap Product(s): IBM Cognos ReportNet, IBM Cognos 8 Area of Interest: Performance
2 Copyright Copyright 2008 Cognos ULC (formerly Cognos Incorporated). Cognos ULC is an IBM Company. While every attempt has been made to ensure that the information in this document is accurate and complete, some typographical errors or technical inaccuracies may exist. Cognos does not accept responsibility for any kind of loss resulting from the use of information contained in this document. This document shows the publication date. The information contained in this document is subject to change without notice. Any improvements or changes to the information contained in this document will be documented in subsequent editions. This document contains proprietary information of Cognos. All rights are reserved. No part of this document may be copied, photocopied, reproduced, stored in a retrieval system, transmitted in any form or by any means, or translated into another language without the prior written consent of Cognos. Cognos and the Cognos logo are trademarks of Cognos ULC (formerly Cognos Incorporated) in the United States and/or other countries. IBM and the IBM logo are trademarks of International Business Machines Corporation in the United States, or other countries, or both. All other names are trademarks or registered trademarks of their respective companies. Information about Cognos products can be found at www.cognos.com This document is maintained by the Best Practices, Product and Technology team. You can send comments, suggestions, and additions to cscogpp@ca.ibm.com.
3 Contents 1 WHAT IS THE JAVA HEAP?... 4 2 WHAT IS THE JVM?... 4 3 WHERE DOES IBM COGNOS REPORTNET (CRN) USE THE JVM?... 4 4 DETERMINING THE CORRECT HEAP SETTINGS... 4 5 USING A LARGE HEAPS ON SOLARIS... 5 5.1 USEFUL WEBSITES...5 6 LIST OF JVM ARGUMENTS... 6 7 ADDITIONAL JAVA HOTSPOT ARGUMENTS... 6
4 1 What is the java heap? The heap is the area of memory in which the Java Virtual Machine (JVM) allocates new Java objects; the fast majority of the JVM's memory usage is its heap. 2 What is the JVM? Contains 2 VMs inside the binary that's executed to start up Java applications. o Client VM o Server VM Each VM is optimized according to the needs of the client and server applications. JVM's top priority is reducing startup time and minimizing the latency produced when the garbage collector reclaims memory. By default Java uses the client VM. The server VM can be selected by passing the - server command line option to the JVM on startup. o Do not assume the server VM will be faster! 3 Where does CRN use the JVM? CRN by default uses JVM that comes with JRE 1.3.1 On startup the "crn\bin\<<startup.bat>> or <<startup.sh>>" is called. The following is set o JAVA_HOME (Defaults to JRE 1.3.1 unless you have gone through the steps to configure JRE 1.4.1+ found on page 33 of the Installation and Configuration Guide) o CATALINA_OPTS (These are the heap arguements) o CATALINA_TMPDIR The "crn\tomcat4.1.27\bin\<<catalina.bat>> or <<catalina.bat>>" is called. o Starts JVM using the CATALINA_OPTS arguments o Starts Tomcat 4 Determining the correct heap settings. Basically the 32 bit Windows Max Heap (-Xms) is 1536b and the UNIX is 3g. Factors that determine best heap settings: o Operating System (32 bit or 64 bit) o Physical Memory (What is available after the OS is done) o JVM version (The older the version the fewer the options) Initial heap size (-Xms) specifies the amount of OS RAM to allocate to the java heap at the time the JVM starts up. Since CRN is a memory intensive application operating under heavy loads the initial heap is important. If JVM starts up with too little heap and is quickly pounded by users that require many object instantiations, the JVM must repeatedly increase its allocation until it reaches a sufficiently large size for the heap.
5 To avoid this from happening set the minimum heap (-Xms) and the maximum heap (-Xmx) to the same values. Make copy and open the "crn\bin\<<startup.bat>> or <<startup.sh>>" Option for machine with 1GB RAM looks like this o set CATALINA_OPTS=-Xms768m Xmx768m -XX:MaxHeapFreeRatio=70 - XX:NewSize=288m %DEBUG_OPTS% You can configure multiple CRN dispatchers on heavy weight windows machine to increase the utilization of the server. 5 Using a Large Heaps on Solaris Heaps larger than 2GB are available starting with J2SE 1.3.1. These are options that can be used to tune the use of memory by the JVM. Best values for CRN will vary and should be set by measurement. o -Xms3g -Xmx3g This example sets the minimum and maximum total heap size to 3GB. The default maximum size is 64MB, but for many server applications it makes sense to be much larger. The g suffix may be replaced by m to measure in megabytes. Ordinarily the JVM consumes as little memory as possible, starting with a heap of the minimum size specified by the -Xms flag, and adaptively growing as required up to the maximum specified by -Xmx. Setting these to the same value avoids being conservative, and will often improve startup time. o XX:+AggressiveHeap This option instructs the JVM to push memory use to the limit: the overall heap is more than 3850MB, the allocation area of each thread is 256K, the memory management policy defers collection as long as possible, and (beginning with J2SE 1.3.1_02) some GC activity is done in parallel. Because this option sets heap size, do not use the -Xms or -Xmx options in conjunction with -XX:+AggressiveHeap. Doing so will cause the options to override each other's settings for heap size. 5.1 Useful Websites http://java.sun.com/docs/hotspot/vmoptions.html http://jakarta.apache.org/tomcat/tomcat-3.2- doc/uguide/tomcat_ug.html http://publib.boulder.ibm.com/infocenter/wsphelp/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rprf_javamemory.html http://e-docs.bea.com/wls/docs61/perform/jvmtuning.html
6 6 List of JVM arguments _JVM_ARGS Environment HotSpot Option Description bound_threads -XX:+UseBoundThreads This option forces all threads to be created as bound threads. fixed_size_young_gen -XX:NewSize=<size> Disable young generation -XX:MaxNewSize=<size> for 1.3 -Xmn<size> for 1.4 resizing. To do this on HotSpot, simply set the size of the young generation to a constant. gc_stats -verbose:gc Turns on various forms of ims_concurrent inline_instrs none -XX:MaxInlineSize=<size> -XX:FreqInlineSize=<size> gc statistics gathering. Integer specifying maximum number of bytecode instructions in a method which gets inlined. Integer specifying maximum number of bytecode instructions in a frequently executed method which gets inlined. inline_print -XX:+PrintInlining Print message about inlined methods (debug only) no_parallel_gc none sync_final none yield_interval -XX:DontYieldALotInterval=<ms> (debug only) Interval in milliseconds between yields. monitor_order none 7 Additional Java HotSpot arguments Numbers can include 'm' or 'M' for megabytes, 'k' or 'K' for kilobytes, and 'g' or 'G' for gigabytes (for example, 32k is the same as 32768). Turn on a Boolean flag with -XX:+<option> and off with -XX:-<option>. Flag and Default -XX:-AllowUserSignalHandlers -XX:AltStackSize=16384 -XX:+MaxFDLimit -XX:MaxHeapFreeRatio=70 -XX:MinHeapFreeRatio=40 Description Do not complain if the application installs signal handlers (Solaris Only) Alternate signal stack size (in Kbytes, Solaris Only) Bump the number of file descriptors to max. (Solaris only) Maximum percentage of heap free after GC to avoid shrinking Minimum percentage of heap free after GC to avoid expansion
7 -XX:-UseBoundThreads -XX:-UseLWPSynchronization Bind user level threads to kernel threads (Solaris only) Use LWP-based instead of thread based synchronization. Default is on in J2SE 1.4.0 or higher. (Solaris only) -XX:+UseThreadPriorities -XX:MaxPermSize=64m -XX:-CITime -XX:-PrintTenuringDistribution -XX:TargetSurvivorRatio=50 -XX:+DisableExplicitGC Use native thread priorities Size of the Permanent Generation Time spent in JIT Compiler (1.4 only) Print tenuring age information Desired percentage of survivor space used after scavenge Disable calls to System.gc(), JVM still performs garbage collection when necessary Those flags differing per architecture/os/jvm Verison. "Flag and Default" has the default of Sparc/-server, JVM version 1.3 Flag and Default Description -XX:CompileThreshold=10000 number of method invocations/branches before (re-)compiling [10,000 -server, 1,500 -client] -XX:MaxNewSize=32m -XX:NewRatio=2 -XX:NewSize=2228224 Maximum size of new generation (in bytes) [32m sparc, 2.5m intel for 1.3, no limit for 1.4 as NewRatio is now used to determine MaxNewSize] Ratio of new/old generation sizes [sparc -server: 2, sparc -client: 4 (1.3) 8 (1.3.1+), intel: 12] Default size of new generation (in bytes) [sparc 2.125M, intel: 640k] -XX:PreBlockSpin=10 Spin count variable for use with - XX:+UseSpinning. Controls the maximum spin iterations allowed before entering operating system thread synchronization code. (as of J2SE 1.4.2, Linux only) -XX:ReservedCodeCacheSize=32m Reserved code cache size (in bytes) - maximum code cache size. [Solaris 64- bit: 1024m] -XX:SurvivorRatio=64 -XX:ThreadStackSize=512 Ratio of eden/survivor space size [Solaris: 64, Solaris: 32 (on 1.3.1 and later), Linux/Windows: 8] Thread Stack Size (in Kbytes) (0 means use default stack size) [Sparc: 512, Solaris Intel: 256, Sparc 64bit: 1024 all others 0]
8 -XX:+UseTLE (-XX:+UseTLAB in J2SE 1.4) Use thread-local object allocation [Sparc -server: true, all others: false] -XX:-UseMPSS -XX:-UseSpinning Use Multiple Page Size Support (Solaris 9 only) w/4mb pages for the heap. Do not use with ISM as this replaces the need for ISM. Enable naive spinning on Java monitor before entering operating system thread synchronizaton code. (as of J2SE 1.4.2, Linux only)