Java performance tuning

Java Performance Tuning
@MOHAMMED FAZULUDDIN

Topics
• Overview
• Java Performance Issues And Solutions
• Java Problem Diagnosis
• Java Performance Tuning Tips
• Java Performance Monitoring Tools

Overview
• Java application performance is major concern in most of the
production environments.
• Normally in the production environment we will hear the issues
like…
• The dreaded java.lang.OutOfMemory Error.
• Your application is literally crawling.
• Most of the issues happens because of increasing of heap size and
in proper garbage collection of objects.
• Most of the application which are developed in Java has memory
leakage issue, which will have huge impact on performance.

Overview
• JVM Heap:
• When a Java program started Java Virtual Machine gets some memory
from Operating System. Java Virtual Machine or JVM uses this memory
for all its need and part of this memory is call java heap memory.
• Default size of Heap space in Java is 128MB on most of 32 bit
Sun's JVM but its highly varies from JVM to JVM e.g. default maximum
and start heap size for the 32-bit Solaris Operating System (SPARC
Platform Edition) is -Xms=3670K and -Xmx=64M and Default values
of heap size parameters on 64-bit systems have been increased up by
approximately 30%.
• When JVM starts JVM heap space is equal to the initial size of Heap
specified by -Xms parameter, as application progress more objects get
created and heap space is expanded to accommodate new objects.

Overview
• JVM Heap:
• Java Heap is divided into 3 generations: Young(Eden), Old(Tenured),
and Permanent.

Overview
• Garbage Collection:
• Java has 2 separate threads for GC, one each for young(minor GC) and
old generation(major GC).
• The minor GC (smaller pause, but more frequent) occurs to clean up
garbage in the young generation, while the major GC (larger pause,
but less frequent) cleans up the garbage in the old generation.
• If the major GC too fails to free required memory, the JVM increases
the current memory to help create new object.
• This whole cycle can go on till the current memory reaches the
MaxMemory for the JVM (default is 64MB for client JVM), after which
JVM throws OutOfMemory Error.

Overview
• Garbage Collection:

Overview
• Permanent Generation:
• Class information is stored in the perm generation.
• Also constant strings are stored there.
• Strings created dynamically in your application with String.intern()
will also be stored in the perm generation.
• JVM process memory:
• The windows task manager just shows the memory usage of the
java.exe task/process. It is not unusual for the total memory
consumption of the VM to exceed the value of -Xmx.
• What you see in the TaskManager is the total PAS, while what the
profiler shows is the Java Heap and the PERM(optionally)

Java Performance Issues And Solutions
• Application slow:
• Your application may be crawling because it's spending too much time
cleaning up the garbage , rather than running the app.
Solution: Need to tune the JVM parameters. Take steps to Balance b/w
pause and GC freq.
• Consumes too much memory:
• The memory footprint of the application is related to the number
and size of the live objects that are in the JVM at any given point of
time.
• This can be either due to valid objects that are required to stay in
memory, or because programmer forgot to remove the reference to
unwanted objects (typically known as 'Memory leaks' in java parlance).

• Java.lang.OutOfMemoryError can occur due to 3 possible
reasons:
• JavaHeap space low to create new objects, the solution is Increase by -
Xmx (java.lang.OutOfMemoryError: Java heap space).
• java.lang.OutOfMemoryError, the solution is change the Java heap
space MaxHeap=30528 KB TotalHeap=30528 KB FreHeap=170
KB UsedHeap=30357 KB.
• Permanent Generation low, Increase by XX:MaxPermSize=256m
(java.lang.OutOfMemoryError: PermGen space)
java.lang.OutOfMemoryError: PermGen space
MaxHeap=65088 KB TotalHeap=17616 KB FreeHeap=9692
KB UsedHeap=7923 KB

• java.lang.OutOfMemoryError: .... Out of swap space ...
• JNI Heap runs low on memory, even though the JavaHeap and the
PermGen have memory.
• This is typically happens if you are making lots of heavy JNI calls, but
the JavaHeap objects occupy little space. In that scenario the GC might
not feel the urge to cleanup JavaHeap, while the JNI Heap keeps on
increasing till it goes out of memory.
• If you use java NIO packages, watch out for this issue. DirectBuffer
allocation uses the native heap.
• The NativeHeap can be increased by -
XX:MaxDirectMemorySize=256M (default is 128)

Java Problem Diagnosis
• There are some starting points to diagnose the problem. You may start
with the '-verbose:gc' flag on the java command and see the memory
footprint as the application progresses, till you find a spike.
• You may analyze the logs or use a light profiler like JConsole (part of
JDK) to check the memory graph.
• If you need the details of the objects that are occupying the memory at a
certain point, then you may use JProfiler or AppPerfect which can
provide the details of each object instance and all the in/out
bound references to/from it.
• This is a memory intensive procedure and not meant for production
systems.

• Some of the diagnosis commands for GC and heap size issues…
• GC outputs:
• -verbose:gc , This flag starts printing additional lines to the console,
like given below
• [GC 65620K -> 50747K(138432K), 0.0279446 secs]
[Full GC 46577K -> 18794K(126848K), 0.2040139 secs]
Combined size of live objects before(young+tenured) GC -> Combined size of live
objects(young+tenured) after GC (Total heap size, not counting the space in the
permanent generation
-XX:+PrintHeapAtGC : More details -XX:+PrintGCTimeStamps will additionally
print a time stamp at the start of each collection.
111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]

• hprof output file:
• java –Xrunhprof:heap=sites,cpu=samples,depth=10,thread=y,doe=y
• The heap=sites tells the profiler to write information about memory
utilization on the heap, indicating where it was allocated.
• cpu=samples tells the profiler to do statistical sampling to determine
CPU use.
• depth=10 indicates the depth of the trace for threads.
• thread=y tells the profiler to identify the threads in the stack traces.
• doe=y tells the profiler to produce dump of profiling data on exit.

Java Performance Tuning Tips
• Code change:
• For memory leak issues, it has to be a code change.
• JVM parameters tuning:
• You need to find the behavior of your app in terms of the ratio of young
to old objects, and then tune the JVM accordingly.
• Memory Size: overall size, individual region sizes -ms, -Xms
sets the initial heap size (young and tenured generation ONLY, NOT
Permanent).
• MaxPermSize default value (32mb for -client and 64mb for -
server),tune this to increase the Permanent generation max size.

• GC parameters:
• -Xminf [0-1], -XX:MinHeapFreeRatio[0-100], sets the percentage of
minimum free heap space - controls heap expansion rate.
• -Xmaxf [0-1], -XX:MaxHeapFreeRatio[0-100], sets the percentage of
maximum free heap space - controls when the VM will return unused
heap memory to the OS.
• -XX:NewRatio, sets the ratio of the old and new generations in the
heap. A NewRatio of 5 sets the ratio of new to old at 1:5, making the
new generation occupy 1/6th of the overall heap.
• -XX:SurvivorRatio, sets the ratio of the survivor space to the eden in
the new object area. A SurvivorRatio of 6 sets the ratio of the three
spaces to 1:1:6, making each survivor space 1/8th of the new object
region.

• Monitoring the application by software profiling.
• Need to do Server and JVM tuning.
• Use the Right Hardware and OS for the better performance.
• Code improvement as per the Behavior of your application &
profiling results.
• Use JVM the right way : optimal JVM params.
• Minimize the use of synchronization.
• Use -XX:+UseParallelGC if u have multiprocessors.

• Use multithreading only if it benefits and be aware of the thread
overheads.
• Avoid premature object creation, creation should be as close to the
actual place of use as possible and this is very basic concept that
we tend to overlook.
• Minimize JNI(Java Native Interface) calls in your code.
• Selection of XML APIs , be careful SAX or DOM and make correct
choice.
• Use precompiled xpaths for better performance of the queries.

Java Performance Monitoring Tools
• Jconsole:
• It comes together with JDK 1.5 and above.
• It is a Java Monitoring and Management Console - JMX-compliant
graphical tool for monitoring a Java virtual machine. It can monitor
both local and remote JVMs.
• VisualVM:
• It is a visual tool that integrates several existing JDK software tools and
lightweight memory and CPU profiling capabilities.
• This tool is designed for both production and development time use
and further enhances the capability of monitoring and performance
analysis for the Java SE platform.

Jconsole:

• HeapAnalyzer:
• Allows the finding of a possible Java™ heap leak area through its heuristic
search engine and analysis of the JavaTM heap dump in Java applications.
• It analyzes Java heap dumps by parsing the Java heap dump, creating
directional graphs, transforming them into directional trees, and executing
the heuristic search engine.
• PerfAnal:
• It is a GUI-based tool for analyzing the performance of applications on the
Java 2 Platform.
• You can use PerfAnal to identify performance problems in your code and
locate code that needs tuning..

HeapAnalyzer:

• JAMon:
• It is a free, simple, high performance, thread safe, Java API that allows
developers to easily monitor production applications.
• Eclipse Memory Analyzer:
• It is a fast and feature-rich Java heap analyzer that helps you find
memory leaks and reduce memory consumption.
• GCViewer :
• It is a free open source tool to visualize data produced by the Java VM
options -verbose:gc and -Xloggc:<file>.
• It also calculates garbage collection related performance metrics
(throughput, accumulated pauses, longest pause, etc.).

JAMon:

• AppDynamics:
• Both JConsole and VisualVM ship with the standard Java JDK. These
application performance tools look at your application through the internals
of the JVM run-time, so the metrics they provide are geared towards things
like memory, threads, classes and KPI like JMX metric and MBeans.
• The only drawbacks these tools have is their lack of application context and
ability to run in live production environments continuously, so they can help
developers and support teams pro-actively manage application performance
24/7.
• AppDynamics addresses both limitations of JConsole and VisualVM. It looks
at your JVM through the eyes of your application allowing you to monitor the
performance of business transactions and associated code path execution
whilst your JVM is running in production.

AppDynamics :

• Stagemonitor:
• Stagemonitor offers a Java monitoring agent, that was built with
clustered application stacks in mind.
• Meaning that it aims to monitor applications that are running on a
number of servers.
• The tool integrates with time series databases (TSDB).
• This tool is optimized for handling time series data, along with arrays
of numbers that are indexed by time.
• These databases include Elasticsearch, Graphite and InfluxDB.

• Stagemonitor:
• Stagemonitor includes an agent that sits in your Java application,
sending metrics and request traces to the central database.
• The tool only requires one instance to monitor all applications,
instances and hosts and can be deployed inside your own datacenter.
• On the monitoring side, you can view historical or live data from the
cluster, or directly from the developer server, create custom alerts and
define thresholds for each metric.
• Stagemonitor includes a dashboard, so you can visualize and analyze
the different metrics and requests you’re interested in.

Stagemonitor:

• Pinpoint:
• Pinpoint is an APM tool made for large scale distributed systems.
• It’s modelled after Dapper, a distributed systems tracing infrastructure
built by Google, providing its developers more information about the
behavior of complex distributed systems.

• Pinpoint:
• The tool helps analyze the overall structure of the system and how
components within them are interconnected, by tracing transactions
across distributed applications.
• Meaning that it aims to explain how every transaction gets executed,
trace the flows between the components and (bad joke ahead)
pinpoints problematic areas and potential bottlenecks.
• The dashboard helps visualize how the components are connected, and
lets you monitor active threads inside the applications in real time.
• You can view critical details that include CPU usage, memory/garbage
collection and JVM arguments.

• Pinpoint:

• MoSKito:
• MoSKito offers 3 tools in one…
• MoSKito-Essential:
• The basic standalone project.
• It’s the core of MoSKito functionality that lets you monitor your application
• MoSKito-Central:
• Centralized storage server for keeping the performance data
• MoSKito-Control:
• A tool for monitoring performance of multi-node web applications

• MoSKito:
• To get started, all you need to do is drop the .jar file into the WEB-
INF/lib folder or by including a small new section in the web.xml file.
• Once the tool is up and running, it collects performance data,
analyzing it in real time as well as storing it for historical analysis.
• The tool collects all of your performance metrics, such as threads,
memory, caches, storage, services, registrations, payments, conversion,
SQL, load distribution and so on.
• It doesn’t require code change, supports all of the major app servers
(Tomcat, Jetty, JBoss, WebLogic) and keeps the data locally.

• MoSKito:

• Glowroot:
• Glowroot prides itself on being a fast, clean and simple APM tool.
• It will allow tracing capture for slow requests and errors, and you’ll be
able to log time trace for each user action, as well as SQL capture and
aggregation.
• The tool also presents a historical rollup of all data with configurable
retention.
• It provides charts to visualize response time breakdown and response
time percentiles, and its responsive UI will allow you to monitor your
application from your mobile devices as well as your desktop.

• Glowroot:
• To get started with Glowroot, you need to download and unzip the
main installation file and add -javaagent:path/to/glowroot.jar to your
application’s JVM arguments.
• After you start your application, all that’s left is pointing the browser to
http://localhost:4000.
• Once the tool is up and running, you’ll get continuous profiling (with
filtering options), along with being able to set up alerts for response
time percentiles and MBean attributes.
• Glowroot offers full support for async requests that span multiple
threads, and it supports Tomcat, TomEE, JBoss EAP, Wildfly, Jetty and
Glassfish.

• Glowroot:

• Kamon:
• Kamon is a reactive-friendly toolkit that is built for applications that
run on top of the JVM.
• More specifically, it’s made for applications that are built with the
Typesafe Reactive Platform (using Scala, Akka, Spray and/or Play!), but
still offers support for any other JVM platforms and languages.
• Kamon is distributed as a core module with all the metric recording
and trace manipulation APIs and optional modules that provide
bytecode instrumentation and/or reporting capabilities to your
application.
• It offers a simple API for recording metrics and trace information for
JVM applications.

• Kamon:
• All of Kemon's modules are available through Maven Central, and you
will need to add them as a compile dependency to your project.
• Once you’ve included the modules you’re interested in, simply start up
Kamon, and all of the available modules will be automatically started,
you don’t need to explicitly activate/start them.
• The tracing modules will allow recording data about functionality
executed in your application, and the metrics module will allow you to
control the registration of entities being tracked either by user code or
by instrumentation provided with other Kamon modules.
• It also has other abilities such as filtering, configuring instrument
factories and dispatching metrics subscriptions.

THANKS
• If you feel it is helpful and worthy to share with other people, please share the same

Java performance tuning

More Related Content

What's hot (20)

Viewers also liked (19)

Similar to Java performance tuning (20)

More from Mohammed Fazuluddin (20)

Recently uploaded (20)

Java performance tuning