Showing posts with label gc. Show all posts
Showing posts with label gc. Show all posts

Monday, March 19, 2012

Performance tools and whitepapers

I have captured some of the mostly used tools for performance and monitoring JAVA applications and Database.

Tools in market

J2SDK tools

  • Java Heap Analysis Tooljhat
  • command line utility included in the Solaris and Linux jmap
  • Java Virtual Machine Statistics Monitoring Tool jstat
  • Stack Trace jstack
  • JMX-compliant monitoring tooljConsole
  • Monitoring and Management Using JMX JMX agent
  • Java Virtual Machine Monitoring, Troubleshooting, and Profiling Tool jvisualvm
  • Open Source GC Viewer

Whitepapers

Visitors, please share here any other tool come across.

Saturday, December 26, 2009

Java Management Extensions (JMX)

Java Management Extensions (JMX)

Application is running for a long time suddenly started performing not good. We do not have any clue at this time. Idea started early 1998, there should be a way to interact the application from a local/remote vM to monitor and maintain the resource. For example, HeapSize almost reached maxSize and full collector not yet triggered, in this time we could make a request for GC from our application. This may not be the right solution, however, we can avoid OOM Exception.

In clustered environment, application may share the same configuration. User may update property in one node, which has to be replicated in other environment in flexible way. We cannot use tightly coupled model, since in failover scenario this will cause more pain to us. JMX Remote API, solves this problem by Change notification mechanism.

JSR details:

  • JSR 3 - Java Management Extensions
  • JSR 160 - JMX Remote API
  • JSR 255 - JMX 2.0


Typical uses of the JMX technology include:

  • Consulting and changing application configuration
  • Accumulating statistics about application behavior and making them available
  • Notifying of state changes and erroneous conditions.

The resources are instrumented as JAVA Object, known as Managed Beans(MBean). MBeans and its services sare registered in a Object Server, known as MBean Server or JMX agents. JMX Connectors helps agent to connect remote VM.

  • enables Java applications to be managed without heavy investment
  • provides a standard way to manage Java technology-based applications, systems, and networks
  • can be used for out-of-the-box management of the Java VM
  • provides a scalable, dynamic management architecture
  • leverages existing standard Java technologies
  • integrates easily with existing management solutions and emerging technologies. JMX solutions can use lookup and discovery services and protocols such as JiniTM network technology and the Service Location Protocol (SLP).

Examples TechNote

Thursday, December 24, 2009

Oracle JRockit : OutOfMemoryError

Oracle JRockit : OutOfMemoryError

Thread Local Area and LargeObjectOrArray


In JRockit, Each thread allocates TLA (Thread Local Area) to store short living objects, and benefits GC to reclaim space. The repective thread can then allocate
objects in its TLA without synchronizing with other threads. If particular TLA size become full, then new TLA will be alotted. In general, we think that by specifying bigger number for TLA we get best performance. But reality is not that case, whenever new thread starts, TLA size has to be reserved with minimum space mentioned in tlasize.



We can specify what could be the largeObject or Array size needs to be stored in TLA, others goes to Heap. Recommendation would be, -XXtlasize:min and -XXlargeObjectLimit has to be equivalent and -XXtlasize:preferred size must to set minimum double the -XXlargeObjectLimit value.



-XXtlasize:min=3k -XXtlasize:preferred=10k -XXlargeObjectLimit=3k

Above configuration tells JVM that 3k objects are larger and it should not go to TLA. Each TLA can grow maximum 10k. If application starts/maintains maximum of 100 threads and all operates on its own data (mean, no synchronization required), then specifying bigger number for TLA, would help to increase the application.



Exception in thread "PoolThread" java.lang.OutOfMemoryError: allocLargeObjectOrArray - Object size: 586154000, Num elements: 586153984
Cause: allocLargeObjectOrArray - Object size: 65552, Num elements: 32768



In the above exception Object Size specifies the size of the Object trying to store in old space with Num elements. This is due to poor garbage collection triggered.



Nursery Size


-Xns option used to specify the size of Nursery. Garbage collection happens quickly in Smaller nursery and larger size takes longer. This size has to be defined based on the application memory usage, and eventually it is Performance Engineer responsibility to set memory settings to make sure that as many object as possible are garbage collected by young collection rather than old collection.Recommended value for this size would be half of the free heap size.



-Xns=100m

-XXkeepAreaRatio:<percentage> used to keep the young and old collection frequency. If ratio high young generation will be triggered often.



Garbage Colletor


JRockit R27.3.0 and later releases offers various types of collector. It is our responsibility to find best suiting option to our application.




Static garbage collector


-Xgc:<strategy>
-Xgc:genpar - generational parallel garbage collector
-Xgc:gencon - To use a generational concurrent garbage collector

-Xgc:singlecon - To use a single-spaced concurrent garbage collector
-Xgc:singlepar - single-spaced parallel garbage collector


Dynamic garbage collector


-XgcPrio:<mode>
-Xgcprio:throughput - gives priority for throughput
-XgcPrio:pausetime -XpauseTarget=40ms - gives priority for pause time
-XgcPrio:deterministic -XpauseTarget:40ms - gives priority for throughput and not crossing pause time


Parallel Mark and Sweep

While garbage collection other Java threads will be paused- genpar and singlepar.



Mostly Concurrent Mark and Sweep

While garbage collection all other JAVA threads will not be paused, if no necessary of synchronization - singlecon and gencon.



For more details, visitOracle JRockit

Sunday, November 18, 2007

OutOfMemoryExceptions

The throughput collector will throw an out-of-memory exception if too much time is being spent doing garbage collection.

For example, if the JVM is spending more than 98% of the total time doing garbage collection and is recovering less than 2% of the heap, it will throw an out-of-memory expection. The implementation of this feature has changed in 1.5. The policy is the same but there may be slight differences in behavior due to the new implementation.

About Generational GC
JVM heap size
Heap Size
Heap Size Options
Heap Size
OutOfMemoryExeception

Thursday, November 15, 2007

About Generational Garbage Collection

The Java HotSpot JVM 1.3 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.

Many objects become available for 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.

About Generational GC
JVM heap size
Heap Size
Heap Size Options
Heap Size
OutOfMemoryExeception

Recent Posts

Unix Commands | List all My Posts

Texts

This blog intended to share the knowledge and contribute to JAVA Community such a way that by providing samples and pointing right documents/webpages. We try to give our knowledege level best and no guarantee can be claimed on truth. Copyright and Terms of Policy refer blogspot.com