Download IBM Cognos ReportNet and the Java Heap Proven Practice

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
Proven Practice
IBM Cognos ReportNet and the
Java Heap
Product(s): IBM Cognos ReportNet, IBM Cognos 8
Area of Interest: Performance
IBM Cognos ReportNet and the Java Heap
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
[email protected] .
IBM Cognos Proprietary Information
IBM Cognos ReportNet and the Java Heap
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
IBM Cognos Proprietary Information
IBM Cognos ReportNet and the Java Heap
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.
IBM Cognos Proprietary Information
IBM Cognos ReportNet and the Java 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
•
•
•
•
•
•
•
5.1
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.
Useful Websites
• http://java.sun.com/docs/hotspot/VMOptions.html
•
http://jakarta.apache.org/tomcat/tomcat-3.2doc/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
IBM Cognos Proprietary Information
IBM Cognos ReportNet and the Java Heap
6
6 List of JVM arguments
_JVM_ARGS Environment
bound_threads
HotSpot Option
-XX:+UseBoundThreads
fixed_size_young_gen
-XX:NewSize=<size>
-XX:MaxNewSize=<size> for 1.3
-Xmn<size> for 1.4
gc_stats
-verbose:gc
ims_concurrent
inline_instrs
none
-XX:MaxInlineSize=<size>
-XX:FreqInlineSize=<size>
inline_print
-XX:+PrintInlining
no_parallel_gc
sync_final
yield_interval
none
none
-XX:DontYieldALotInterval=<ms>
monitor_order
none
Description
This option forces all
threads to be created as
bound threads.
Disable young generation
resizing. To do this on
HotSpot, simply set the
size of the young
generation to a constant.
Turns on various forms of
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.
Print message about
inlined methods (debug
only)
(debug only) Interval in
milliseconds between
yields.
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
Description
Do not complain if the application
installs signal handlers (Solaris Only)
-XX:AltStackSize=16384
Alternate signal stack size (in Kbytes,
Solaris Only)
-XX:+MaxFDLimit
Bump the number of file descriptors to
max. (Solaris only)
-XX:MaxHeapFreeRatio=70
Maximum percentage of heap free after
GC to avoid shrinking
-XX:MinHeapFreeRatio=40
Minimum percentage of heap free after
GC to avoid expansion
IBM Cognos Proprietary Information
IBM Cognos ReportNet and the Java Heap
7
-XX:-UseBoundThreads
Bind user level threads to kernel threads
(Solaris only)
-XX:-UseLWPSynchronization
Use LWP-based instead of thread based
synchronization. Default is on in J2SE
1.4.0 or higher. (Solaris only)
-XX:+UseThreadPriorities
Use native thread priorities
-XX:MaxPermSize=64m
Size of the Permanent Generation
-XX:-CITime
Time spent in JIT Compiler (1.4 only)
-XX:-PrintTenuringDistribution
Print tenuring age information
-XX:TargetSurvivorRatio=50
Desired percentage of survivor space
used after scavenge
Disable calls to System.gc(), JVM still
performs garbage collection when
necessary
-XX:+DisableExplicitGC
Those flags differing per architecture/OS/JVM Verison. "Flag and Default"
has the default of Sparc/-server, JVM version 1.3
Flag and Default
-XX:CompileThreshold=10000
Description
number of method invocations/branches
before (re-)compiling [10,000 -server,
1,500 -client]
-XX:MaxNewSize=32m
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]
-XX:NewRatio=2
Ratio of new/old generation sizes [sparc
-server: 2, sparc -client: 4 (1.3) 8
(1.3.1+), intel: 12]
-XX:NewSize=2228224
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)
Reserved code cache size (in bytes) maximum code cache size. [Solaris 64bit: 1024m]
-XX:ReservedCodeCacheSize=32m
-XX:SurvivorRatio=64
Ratio of eden/survivor space size
[Solaris: 64, Solaris: 32 (on 1.3.1 and
later), Linux/Windows: 8]
-XX:ThreadStackSize=512
Thread Stack Size (in Kbytes) (0 means
use default stack size) [Sparc: 512,
Solaris Intel: 256, Sparc 64bit: 1024 all
others 0]
IBM Cognos Proprietary Information
IBM Cognos ReportNet and the Java Heap
8
-XX:+UseTLE
(-XX:+UseTLAB in J2SE 1.4)
-XX:-UseMPSS
-XX:-UseSpinning
IBM Cognos Proprietary Information
Use thread-local object allocation [Sparc
-server: true, all others: false]
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)