A Top Down Approach - Starting from System Monitoring Utilities, Deep Dive into various analysis, Case Studies & Bes Practices

1. Java Performance Tuning
Top Down Approach

2. Symptoms
 Memory
 CPU
 I/O
 Devices
 Network

3. Indicators - Windows

4. Indicators - Linux
 Sar, top, dstat,etc.

5. Jumping Board - JConsole
 Study the JVM Args
 Heap Usage should follow a saw tooth pattern
denoting there is no leak
 There should not be any anonymous threads like
‘Thread 1’
 Look for creation of dynamic classes in large numbers
 CPU Usage

6. Heap ?
 Heap is utilized throughout the Object Lifecycle starting from new object
creation, variable references, dereferences by variables going out of
scope and finally till Garbage Collection
 Object references can be represented in a tree fashion as we do deep
references and the cumulative size retained at each level can be
determined using offline utilities
 There can multiple top level objects in the current program flow
context that can retain individual object tree
 A parent node should be shallow in size such that it does not retain
memory compared to its child nodes
 When there is a large difference in retained size between parent and
child node, i.e drops, there is a possibility of memory leak

7. Deep Dive – Heap Analysis
 Online
 VisualVM, JRockit, IBM Health Center
 Profilers
 Offline
 IBM Heap Analyzer
 Eclipse MAT

8. Deep Dive – Memory Leaks

9. CPU ?
 Thread dumps provides thread status, monitors,
number of threads waiting for the monitor and call
stack of methods
 Comparing thread dumps taken at frequent intervals
can reveal as to which tasks (call stack) are being
performed across thread dumps
 Online profiling tools can provide hotspot methods
 Snapshots can provide thread wise call tree, along
with response time

10. Deep Dive – Threads & Call Stack
 Online
 VisualVM, JRockit, IBM Health Center
 Profilers
 Offline
 IBM Thread and Monitor Dump Analyzer

11. Deep Dive – Threads & Call Stack

12. I/O ?
 Study the read, writes and response time of
the Java process and identify the device
that is heavily utilized or not responding
 Study the network traffic in terms of
number of connections, bytes sent /
received and transfer rate

13. Deep Dive – I/O
 Based on the heavy reads / writes look for
input and output streams without
buffering, multiple reads of same
resources, unnecessary serialization, etc
 Re-use of connection, file transfer in
uncompressed form, releasing network
resources (such as result set, statement and
connection), etc

14. Performance Case Study - Heap
 Source - http://javaeesupportpatterns.blogspot.in/2012/07/5-
tips-for-proper-java-heap-size.html

15. Performance Case Study - CPU
 Loading of DTM Manager for every XPath
Evaluation
 Source http://stackoverflow.com/questions/6340802/java-xpath-apache-jaxp-
implementation-performance

16. Best Practices
 Understand your application environment
such as firewall, layers (web, app &
db), third party data providers if any
 Use offline tools and less intrusive tools in
production environments
 Look for tools provided by the JVM vendor
or the Application Server vendor
 Use JMeter for recreating production
scenario in your environment