S85

Java tuning on z (CICS, IMS, DB2)
Scott Clee - CICS Test Architect

Scott_Clee@uk.ibm.com
Abstract
Java on the mainframe has reached a level of maturity. Big mainframe players
support it and its popularity has radically increased due skills availability and
competitive pricing models on the z platform. Having answered the question "Can
we run it?". Many people are now asking "How can we run it well?". This
informative presentation brings together Java tuning information from a collection
of CICS, IMS and DB2 experts.
Audience: Sys Prog
Skill level: Intermediate, Advanced
03/06/2009 GUIDE SHARE EUROPE 2

Important Disclaimer
THE INFORMATION CONTAINED IN THIS PRESENTATION IS PROVIDED FOR INFORMATIONAL
PURPOSES ONLY.
WHILE EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE
INFORMATION CONTAINED IN THIS PRESENTATION, IT IS PROVIDED “AS IS”, WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED.
IN ADDITION, THIS INFORMATION IS BASED ON IBM’S CURRENT PRODUCT PLANS AND STRATEGY,
WHICH ARE SUBJECT TO CHANGE BY IBM WITHOUT NOTICE.
IBM SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF THE USE OF, OR OTHERWISE
RELATED TO, THIS PRESENTATION OR ANY OTHER DOCUMENTATION.
NOTHING CONTAINED IN THIS PRESENTATION IS INTENDED TO, OR SHALL HAVE THE EFFECT OF:
• CREATING ANY WARRANTY OR REPRESENTATION FROM IBM (OR ITS AFFILIATES OR ITS OR THEIR
SUPPLIERS AND/OR LICENSORS); OR
• ALTERING THE TERMS AND CONDITIONS OF THE APPLICABLE LICENSE AGREEMENT GOVERNING
THE USE OF IBM SOFTWARE.

Agenda
Java considerations
JVM tuning
JVM on z
CICS tuning
DB2 tuning
IMS tuning
Tooling
Links

Java considerations

Similarities and differences between JVMs and platforms
The IBM J9 JVM is the same across all platforms

– Tools and techniques available on distributed platforms are applicable to z/OS
– In the past CICS would only support specific JVM parameters but this is not the case now
Different vendor JVMs may have varying parameters and default settings
– IBM J9 JVM runs in server mode
– Sun HotSpot JVM defaults to client mode
Certain aspects of JVM tuning are common across all platforms
– Application tuning
– Heap management
– Garbage collection

JVM tuning

Main areas for performance consideration
Server performance can be impacted by:
– Application’s behaviour with objects
– Use of heap
– Frequency and type of garbage collection
Performance can be increased with proper configuration of JVM parameters
– This provides one of the biggest opportunities for performance gains
Application
Garbage collection Memory usage

Application tuning
Java frees the programmer from the burden of memory management
– Ensures applications are more robust
– Brings in its own set of considerations and practices
Watch out for object abuse!
Verify these main areas:
– Application is not over utilizing objects
– Application is not leaking objects
– Java heap parameters are set properly to handle a given object usage pattern

Heap size
The Java heap is where the objects of a Java program live. It is a repository for live objects,
dead objects, and free memory. When an object can no longer be reached from any pointer
in the running program, the object is garbage.
The JVM heap size determines how often and how long the VM spends collecting garbage.
An acceptable rate for garbage collection is application-specific and should be adjusted
after analyzing the actual time and frequency of garbage collections.
If you set a large heap size, full garbage collection is slower, but it occurs less frequently. If
you set your heap size in accordance with your memory needs, full garbage collection is
faster, but occurs more frequently.
The goal of tuning your heap size is to minimize the time that you spend doing garbage
collection while maximizing the number of clients that you can handle at a given time.
The Java heap parameters also influence the behavior of garbage collection. Increasing the
heap size supports more object creation. Because a large heap takes longer to fill, the
application runs longer before a garbage collection occurs. However, a larger heap also
takes longer to compact and causes garbage collection to take longer

Setting the heap size
-Xmx
-Xms
Append the letter `k' or `K' to the value to indicate kilobytes, `m' or `M' to indicate
megabytes, and `g' or `G' to indicate gigabytes.
It is good practice with server-side Java applications like Resin to set the
minimum -Xms and maximum -Xmx heap sizes to the same value.
If you monitor your java process with an OS tool like top or taskmanager, you may
see the amount of memory you use exceed the amount you have specified for -
Xmx. -Xmx limits the java heap size, java will allocate memory for other things,
including a stack for each thread. It is not unusual for the total memory
consumption of the VM to exceed the value of -Xmx.
You achieve best performance by individually tuning each of your applications.
For performance analysis, the initial and maximum heap sizes should be equal.

Determining heap size
1. Monitor the performance of WebLogic Server under maximum load while running your application.
2. Use the -verbosegc option to measure exactly how much time and resources are put into garbage collection.
3. Turn on verbose garbage collection output for your Java VM and redirect both the standard error and standard output to a log file.
4. See Turning On Verbose Garbage Collection and Redirecting Output.
5. Analyze the following:
1. How often is garbage collection taking place? In the weblogic.log file, compare the time stamps around the garbage collection.
2. How long is garbage collection taking? Full garbage collection should not take longer than 3 to 5 seconds.
3. What is your average memory footprint? In other words, what does the heap settle back down to after each full garbage collection? If the
heap always settles to 85% free, you might set the heap size smaller.
6. If you are using 1.3 Java HotSpot JVM, set generation sizes.
• Specifying Heap Size Values.
7. Make sure that the heap size is not larger than the available free RAM on your system.
1. Use as large a heap size as possible without causing your system to "swap" pages to disk. The amount of free RAM on your system
depends on your hardware configuration and the memory requirements of running processes on your machine. See your system
administrator for help in determining the amount of free RAM on your system.
8. If you find that your system is spending too much time collecting garbage (your allocated "virtual" memory is more than your RAM can handle), lower
your heap size.
• Typically, you should use 80% of the available RAM (not taken by the operating system or other processes) for your JVM.
9. If you find that you have a large amount of RAM remaining, run more WebLogic Servers on your machine.

Garbage collection patterns
For all three configurations, the total time
in garbage collection is approximately
15%. This example illustrates an
important concept about the Java heap
and its relationship to object utilization.
There is always a cost for garbage
collection in Java applications.
If the application is not over utilizing
objects and has no memory leaks, the
state of steady memory utilization is
reached. Garbage collection also occurs
less frequently and for short duration.
If the heap free space settles at 85% or
more, consider decreasing the maximum
heap size values because the application
server and the application are under-
utilizing the memory allocated for heap.
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rprf_javamemory.html

Generational garbage collection
The 1.3 Java HotSpot JVM uses generational garbage collection. While naive garbage collection
examines every living object in the heap, generational garbage collection considers the lifetime of an
object to avoid extra work.
The heap is divided into two general areas: New and Old. The New generation area is sub-divided further
into Eden and two survivor spaces. Eden is the area where new objects are allocated. When garbage
collection occurs, live objects in Eden are copied into the next survivor space. Objects are copied
between survivor spaces in this way until they exceed a maximum threshold, and then they are moved
out of the New area and into the Old. For information about specifying the size and ratios of the New and
Old generation areas, see Specifying Heap Size Values.
Many objects become garbage shortly after being allocated. These objects are said to have "infant
mortality." The longer an object survives, the more garbage collection it goes through, and the slower
garbage collection becomes. The rate at which your application creates and releases objects determines
how often garbage collection occurs. Attempt to cache objects for re-use, whenever possible, rather than
creating new objects.
Knowing that a majority of objects die young allows you to tune for efficient garbage collection. When you
manage memory in generations, you create memory pools to hold objects of different ages. Garbage
collection can occur in each generation when it fills up. If you can arrange for most of your objects to
survive less than one collection, garbage collection is very efficient. Poorly sized generations cause
frequent garbage collection, impacting your performance.

Garbage collection
There are essentially two GC threads running. One is a very lightweight thread
which does "little" collections primarily on the Eden (a.k.a. Young) generation of
the heap. The other is the Full GC thread which traverses the entire heap when
there is not enough memory left to allocate space for objects which get promoted
from the Eden to the older generation(s).
If there is a memory leak or inadequate heap allocated, eventually the older
generation will start to run out of room causing the Full GC thread to run (nearly)
continuously. Since this process "stops the world", Resin won't be able to respond
to requests and they'll start to back up.
The amount allocated for the Eden generation is the value specified with -Xmn.
The amount allocated for the older generation is the value of -Xmx minus the -
Xmn. Generally, you don't want the Eden to be too big or it will take too long for
the GC to look through it for space that can be reclaimed.
Does the IBM JVM support -Xmn ?

You can use garbage collection to evaluate application performance health. By
monitoring garbage collection during the execution of a fixed workload, you gain
insight as to whether the application is over-utilizing objects. Garbage collection
can even detect the presence of memory leaks.
For this type of investigation, set the minimum and maximum heap sizes to the
same value. Choose a representative, repetitive workload that matches
production usage as closely as possible, user errors included.
To ensure meaningful statistics, run the fixed workload until the application state
is steady. It usually takes several minutes to reach a steady state.
-Xverbosegc:file=/tmp/gc$$.out
– This option redirects -verbosegc messages to a file, allowing you to separate
your garbage collection messages from the rest of the messages on stderr.
– It also provides a performance advantage because writes to files are buffered
better than writes to a character stream like stderr.

If the information indicates a garbage collection bottleneck, there are two ways to
clear the bottleneck. The most cost-effective way to optimize the application is to
implement object caches and pools. Use a Java profiler to determine which
objects to target. If you can not optimize the application, adding memory,
processors and clones might help. Additional memory allows each clone to
maintain a reasonable heap size. Additional processors allow the clones to run in
parallel.

Good garbage collection messages
– <GC(32): GC cycle started Fri Jun 12 09:20:25 2009
– <GC(32): freed 0 bytes from Transient Heap 100% free (523776/523776) and...>
– <GC(32): freed 5676656 bytes, 56% free (7763712/13761024), in 12 ms>
– <GC(32): mark: 10 ms, sweep: 2 ms, compact: 0 ms>
– <GC(32): refs: soft 0 (age <= 32), weak 0, final 0, phantom 0>
Bad garbage collection messages

– <AF[7]: Allocation Failure. need 16400 bytes, 770 ms since last AF>
– <AF[7]: managing allocation failure, action=3 (114624/9697792)>
– <GC(8): need to expand mark bits for 13761024-byte heap>
– <GC(8): expanded mark bits by 63488 to 215016 bytes>
– <GC(8): need to expand alloc bits for 13761024-byte heap>
– <GC(8): expanded alloc bits by 63488 to 215016 bytes>
– <GC(8): need to expand FR bits for 13761024-byte heap>
– <GC(8): expanded FR bits by 126976 to 430036 bytes>
– <GC(8): expanded heap by 4063232 to 13761024 bytes, 30% free>
– <AF[7]: completed in 1 ms>

VERBOSE=gc
Writes XML to stderr
Example:
<?xml version="1.0" ?>
<verbosegc version="20081027_AB">
<initialized>
<attribute name="gcPolicy" value="-Xgcpolicy:optthruput" />
<attribute name="maxHeapSize" value="0x4000000" />
<attribute name="initialHeapSize" value="0x4000000" />
<attribute name="compressedRefs" value="false" />
<attribute name="pageSize" value="0x1000" />
<attribute name="requestedPageSize" value="0x1000" />
</initialized>
</verbosegc>

Memory leaks
Memory leaks in the Java language cause excessive garbage collection
– More damaging than memory overuse because it ultimately leads to system instability.
Garbage collection occurs more frequently until the heap is exhausted and Java
code fails with a fatal out-of-memory exception
Memory leaks occur when an unused object has references that are never freed
– Commonly occur in collection classes such as Hashtable
Can still hold a reference to an object even after real references are deleted

Tips for spotting memory leaks
Repeat runs with increasing duration
Graph of used memory should have a sawtooth shape
– Each drop corresponds to a garbage collection
There is a memory leak if one of the following occurs:
– Sawtooth pattern looks like a staircase
– Sawtooth pattern has an irregular shape.
Look at the difference between number of freed and allocated objects
– If the gap between the two increases over time, there is a memory leak.

JVM on z

JDK 1.4.2 JVM storage (Classcache=YES)
Worker JVM XMX +10 meg
Subsequent JVMs Worker JVM XMX +10 meg

Master JVM XMX +10 meg
Classcache JVMCCSIZE
1st JVM + Master Common code 18 meg
Storage Cushion 20 meg
ELSQA/ESWA Shrlibrgnsize
Java 5 JVM storage (Classcache=YES)
JVM XMX +18 meg

Subsequent JVMs JVM XMX +18 meg
JVM XMX +18 meg
Classcache JVMCCSIZE
1st JVM Common code 5 meg
ELSQA/ESWA Shrlibrgnsize
JDK 1.4.2 JVM storage (Classcache=No)
JVM XMX +26 meg
subsequent JVMs JVM XMX +26 meg
JVM XMX +26 meg

ELSQA /ESWA Shrlibrgnsize
Java 5 JVM storage (Classcache=No)
JVM XMX +20 meg
subsequent JVMs JVM XMX +20 meg
JVM XMX +20 meg

ELSQA /ESWA Shrlibregionsize

Tuning Unix System Services (USS) for your JVM
Set your JVM and CICS executables to be in a USS shared library (Shared
Library Extended)
– extattr +l jvm*
– extattr +l cics*.so
Put directory containing application classes into zFS

CICS tuning

JVM modes
Single use
Continuous (reusable but not reset)

Single use JVM
REUSE=NO in JVM Profile
Cannot be used with shared classcache
JVM destroyed and rebuilt between program invocations

Continuous mode JVM
REUSE=YES in JVM Profile
Can be used with shared classcache
JVM not reset between program invocations
Highest level of performance. Less protection from effects of an
earlier program invocation in the same JVM

Java resource usage
2Gb 64-bit - “bar”
Heap Heap Heap

JVM JVM JVM
16 Mb 31-bit - “line”
For each JVM program running in CICS, there is an MVS JVM running in the CICS address space

Setting up the shared classcache
Specify the following SIT parameters:
– JVMCCSTART=YES
– JVMCCSIZE=64M
Specify the following in the JVM profile
– CLASSCACHE=YES
JIT’d classes are not cached due to a new JIT optimization method
For set up info on Java 1.4.2 which use master and worker JVMs see
– zAAP and the art of CICS Java tuning (GSE Nordic 2005)
http://www.gse-nordic.org/Working%20Groups/GNRC/Conferences/2005/CICS%20Stream/s29

Tuning the shared classcache
1. Run workload for long enough to ensure all classes are loaded and JITed
2. Use CEMT INQ CLASSCACHE to check on the amount of storage
3. Set JVMCCSIZE SIT parameter large enough to contain the amount of storage
used

The CICS garbage collection model
New Garbage Collection scheduling algorithm (introduced in CICS TS 3.2)
– Occurs at a target heap utilisation
GC_HEAP_THRESHOLD parameter in the JVM profile (default 85%)
100% implies no CICS-scheduled GC
– Performed asynchronously in a CICS system task
Application does not suffer bad response times simply because a scheduled GC takes place
New transaction CJGC
Unscheduled GC within the JVM can still occur at any time

– But with a little tuning you can minimise the likelihood of this happening

Tuning LE enclaves for your CICS JVMs
JVM LE enclave uses storage allocations set by CICS
Use user exit DFHJVMRO to modify default settings
– Assembler URM
– Invoked before invoking CEEPIPl to create new LE enclave for JVM

DB2 tuning

Environment tuning hints
Tune your JVM heap
Default heap size is
– ms = 1M
– mx = 8M
Values between 300M and 400M are common in a production environment
Set ms and mx to an equal value
Heap Size Study

Trans/sec
ms=1M,mx=700M ms=200M,mx=200M
ms=700M,mx=700M

Heappools
Set environment variable: _cee_runopts = "heappools(on)“
Controls an optional heap storage management algorithm
– Designed to improve the performance of multithreaded C/C++ applications
– Targetted at applications with high usage of malloc(), calloc(), realloc(), and free()

Environment tuning hints
Recommended DB2 BIND options
– DYNAMICRULES(BIND)
table access privileges of the binder used during program execution
– QUALIFIER
creator (schema name) for unqualified tables and views
Use dynamic SQL statement caching
– Avoids full cost of preparing SQL
– Processing cost close to static SQL
– Recommended for JDBC/SQLJ
– Cursor controlled update/delete executed
– dynamically in SQLJ

General tips
Turn off JDBC autocommit and cursor with hold
Use VARCHAR or VARGRAPHIC as SQL column data type for string columns
If most of the database processing is from Java applications then use Unicode as the database encoding
scheme instead of EBCDIC
Use matching java data type that matches SQL column data type
Only read and update SQL columns as absolutely necessary
Code to explicitly close resources (SQL results sets, prepared statements, callable statements)
Use SQLJ (static SQL) instead of JDBC (dynamic SQL)
Turn on dynamic statement caching and tune size of cache for JDBC (dynamic SQL)
For JDBC (dynamic SQL) used in web based transaction processing use parameter markers rather than
literals
Use BIND options of ISOLATION(CS) and CURRENTDATA(NO) for SQLJ packages
Use BIND option of CURRENTDATA(NO) for ISOLATION(CS) package for JDBC
Do not allow JDBC isolation level to default - use ISOLATION(CS)
Use SQLJ and/or JDBC batching and multi row operations for bulk processing
Use JCC Type 2 driver if application server local (same LPAR) as DB2, otherwise use JCC Type 4 driver
for application server connecting over distributed connection to DB2.

IMS tuning

Environment tuning
Software pre-reqs
– IBM Java 5 JDK for z/OS
– IMS V9 with enabling PTF for Java 5 JDK or IMS V10
JVM requires tuning
– Don’t start with un-tuned JVM
Customer case CPU time (SMF based) of 140 seconds (Java Defaults) versus 78 seconds (with
Java tuning) versus 2.4 seconds (Java tuning and WFI)
– Check region parameter to avoid out of memory exceptions
– REGION=0M uses less storage than REGION=392M
– When calculating Region size take into account that garbage collection requires up to –
mx parameters amount of additional storage

Environment tuning
Default LE Settings are unsuitable for Java
Consider customizing LE option like recommended for WAS on z/OS:
ANYHEAP(2M,1M,ANY,FREE),
HEAP(80M,4M,ANY,KEEP),
HEAPPOOLS(ON,8,10,32,10,128,10,256,10,1024,10,2048,10,0,10,0,10,0,10,0,10,0,10,0,
10),
STACK(64K,16K,ANY,KEEP,128K,128K),
STORAGE(NONE,NONE,NONE,0K),
THREADSTACK(OFF,64K,16K,ANY,KEEP,128K,128K),
TERMTHDACT=(UADUMP),
XPLINK=(ON),
POSIX=(ON)
LE Parameters Tuning
RPTSTG=(ON) will display usage and suggested values

Environment tuning
JVM tuning in MPR
– Environment variable for COBOL JVM Options must be used for JVM parameters:
COBJVMINITOPTIONS=-Xoptionsfile=/u/itso12/jvm.properties
– In PL/I JVM Options are supplied at JVM API invokation as string (recommendation to point to
jvm.properties file)
– Sample jvm.properties file:
-Xcodecache=16M
-Xquickstart
-Xshareclasses:name=imscobol
-Xscmx32M
-Xmx96M
-Xms64M
Java Profiling
– Method to find the Java code where most CPU is spend and which Java methods are executed how
often during program invocation
– Currently not available in IMS regions
– Eclipse TPTP can be used, but has some pitfalls
– Suggesting, execute Java in Batch where profiling is available

Tooling

Real-time analysis - JConsole
Free tool supplied with the JVM
– Can be found in bin directory
Connects to be a long running JVM
– or a JVM in a CICS pool
Add these parameters to server JVM
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.port=<port number>
Article on using jConsole
– http://java.sun.com/javase/6/docs/technotes/guides/management/jconsole.html

Write your own - java.lang.management
ClassLoadingMXBean
– The management interface for the class loading system of the Java virtual machine.
CompilationMXBean
– The management interface for the compilation system of the Java virtual machine.
GarbageCollectorMXBean
– The management interface for the garbage collection of the Java virtual machine.
MemoryManagerMXBean
– The management interface for a memory manager.
MemoryMXBean
– The management interface for the memory system of the Java virtual machine.

Write your own - java.lang.management
MemoryPoolMXBean
– The management interface for a memory pool.
OperatingSystemMXBean
– The management interface for the operating system on which the Java virtual machine
is running.
RuntimeMXBean
– The management interface for the runtime system of the Java virtual machine.
ThreadMXBean
– The management interface for the thread system of the Java virtual machine.

java.lang.management – an example
Example program to print heap usage:
public static void main(String[] args)
{
java.lang.management.MemoryMXBean memory = ManagementFactory.getMemoryMXBean();
System.out.println(memory.getHeapMemoryUsage());
}
Output from laptop JVM:

init = 4194304(4096K) used = 643944(628K) committed = 4194304(4096K) max = 536870400(524287K)
http://java.sun.com/javase/6/docs/api/java/lang/management/package-summary.html

Offline dump analysis tools
Heap analyzer
– Graphical tool for discovering possible heap leaks
– http://www.alphaworks.ibm.com/tech/heapanalyzer/download
Eclipse memory analyzer tool (MAT)
– http://www.eclipse.org/mat/
IBM DTFJ adapter for Eclipse MAT
– https://www.ibm.com/developerworks/java/jdk/tools/mat.html

Offline garbage collection analysis tools
Extensible Verbose Toolkit (EVTK)
– Data visualizer for verbose GC and GC
trace
– http://www-
128.ibm.com/developerworks/forums/thread.jspa?messageI
D=13940438
IBM Monitoring and Diagnostic Tools for

Java
– http://www.ibm.com/developerworks/java/library/j-
ibmtools2/index.html

Links

Useful Java blogs and posts
/dev/websphere
– http://www.devwebsphere.com/devwebsphere/
Eclipse MAT blog
– http://dev.eclipse.org/blogs/memoryanalyzer/
The Power of Aggregation: Making Sense of the Object in a Heap Dump
– http://dev.eclipse.org/blogs/memoryanalyzer/2008/05/08/the-power-of-aggregation-
making-sense-of-the-objects-in-a-heap-dump/
Automated Heap Dump Analysis: Finding Memory Leaks with One Click
– http://dev.eclipse.org/blogs/memoryanalyzer/2008/05/27/automated-heap-dump-
analysis-finding-memory-leaks-with-one-click/#more-54

3-part tutorial on IBM JVM garbage collector
Understanding the IBM Java Garbage Collector part 1
– http://www.ibm.com/developerworks/ibm/library/i-garbage1/
– http://www.ibm.com/developerworks/ibm/library/i-garbage2/
– http://www.ibm.com/developerworks/library/i-garbage3.html

Links
WAS – Tuning Java virtual machines
– http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websph
ere.express.doc/info/exp/ae/tprf_tunejvm.html
WAS – Java memory tuning tips
– http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websph
ere.express.doc/info/exp/ae/rprf_javamemory.html
Fine-tuning Java garbage collection performance
– http://www.ibm.com/developerworks/ibm/library/i-gctroub/
Monitoring and management tools
– http://java.sun.com/javase/6/docs/technotes/tools/index.html#monitor
– http://java.sun.com/j2se/1.5.0/docs/tooldocs/index.html#manage
Monitoring and management for the Java platform
– http://java.sun.com/javase/6/docs/technotes/guides/management/index.html

zSeries
PD/CICS/Icing
Sales - CICS
Communities
CICS Communities and Information Home page
CICS Transaction Server V4.1 & CICS Explorer

– http://ibm.com/cics/tserver/v41/ ibm.com/cics/explorer
CICS Explorer Forum CICS Explorer
Public Forum
– http://tinyurl.com/68bndw
– IBM developerWorks forum with FAQs, Links and resources, ISV Contributions, etc. Ask
questions, suggest improvements, report problems, chat
New! CICS Hub on the Rational COBOL Café CICS Hub
– http://ibm.com/software/rational/cafe/community/cobol/cics
Twitter
– Subscribe to the IBM_System_z channel IBM_CICS CICSFluff to get CICS news
flashes
CICS Blog
– Comment and opinion at TheMasterTerminal.com Twitter
CICS eNews
– Subscribe for news about CICS and related products
YouTube channels Blog
– CICS Explorer - Videos, demos and other cool stuff
– CICSFluff - Other CICS videos
Facebook eNews
– Link
YouTube

Summary
Java considerations
JVM tuning
JVM on z
CICS tuning
DB2 tuning
IMS tuning
Tooling
Links

Questions?

S85

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

S85

Enviado por

Direitos autorais:

Formatos disponíveis

Java tuning on z (CICS, IMS, DB2)

Scott Clee - CICS Test Architect

03/06/2009 GUIDE SHARE EUROPE 2

03/06/2009 GUIDE SHARE EUROPE 3

03/06/2009 GUIDE SHARE EUROPE 4

03/06/2009 GUIDE SHARE EUROPE 5

 The IBM J9 JVM is the same across all platforms

03/06/2009 GUIDE SHARE EUROPE 6

03/06/2009 GUIDE SHARE EUROPE 7

Garbage collection Memory usage

03/06/2009 GUIDE SHARE EUROPE 8

03/06/2009 GUIDE SHARE EUROPE 9

03/06/2009 GUIDE SHARE EUROPE 10

03/06/2009 GUIDE SHARE EUROPE 11

03/06/2009 GUIDE SHARE EUROPE 12

03/06/2009 GUIDE SHARE EUROPE 13

03/06/2009 GUIDE SHARE EUROPE 14

03/06/2009 GUIDE SHARE EUROPE 15

03/06/2009 GUIDE SHARE EUROPE 16

03/06/2009 GUIDE SHARE EUROPE 17

 Bad garbage collection messages

03/06/2009 GUIDE SHARE EUROPE 18

03/06/2009 GUIDE SHARE EUROPE 19

03/06/2009 GUIDE SHARE EUROPE 20

03/06/2009 GUIDE SHARE EUROPE 21

03/06/2009 GUIDE SHARE EUROPE 22

Worker JVM XMX +10 meg

Subsequent JVMs Worker JVM XMX +10 meg

JVM XMX +18 meg

JVM XMX +18 meg

JVM XMX +26 meg

subsequent JVMs JVM XMX +26 meg

JVM XMX +26 meg

JVM XMX +20 meg

subsequent JVMs JVM XMX +20 meg

JVM XMX +20 meg

03/06/2009 GUIDE SHARE EUROPE 26

03/06/2009 GUIDE SHARE EUROPE 27

03/06/2009 GUIDE SHARE EUROPE 28

03/06/2009 GUIDE SHARE EUROPE 29

03/06/2009 GUIDE SHARE EUROPE 30

03/06/2009 GUIDE SHARE EUROPE 31

2Gb 64-bit - “bar”

Heap Heap Heap

03/06/2009 GUIDE SHARE EUROPE 32

03/06/2009 GUIDE SHARE EUROPE 33

03/06/2009 GUIDE SHARE EUROPE 34

 Unscheduled GC within the JVM can still occur at any time

03/06/2009 GUIDE SHARE EUROPE 35

03/06/2009 GUIDE SHARE EUROPE 36

03/06/2009 GUIDE SHARE EUROPE 37

Heap Size Study

03/06/2009 GUIDE SHARE EUROPE 38

03/06/2009 GUIDE SHARE EUROPE 39

03/06/2009 GUIDE SHARE EUROPE 40

03/06/2009 GUIDE SHARE EUROPE 41

03/06/2009 GUIDE SHARE EUROPE 42

03/06/2009 GUIDE SHARE EUROPE 43

03/06/2009 GUIDE SHARE EUROPE 44

03/06/2009 GUIDE SHARE EUROPE 45

03/06/2009 GUIDE SHARE EUROPE 46

03/06/2009 GUIDE SHARE EUROPE 47

03/06/2009 GUIDE SHARE EUROPE 48

The IBM J9 JVM is the same across all platforms

Bad garbage collection messages

Unscheduled GC within the JVM can still occur at any time

Output from laptop JVM:

IBM Monitoring and Diagnostic Tools for

CICS Transaction Server V4.1 & CICS Explorer