JVM Performance - Revision history

Suhridk: /* Memory footprint tuning */

2013-12-08T18:35:42Z

Memory footprint tuning

Suhridk: /* Memory footprint tuning */

2013-12-08T18:20:23Z

Memory footprint tuning

Suhridk: /* Tuning */

2013-12-08T18:15:08Z

Tuning

Suhridk: /* Tuning */

2013-12-08T18:13:57Z

Tuning

Suhridk: /* Memory footprint tuning */

2013-12-08T18:04:51Z

Memory footprint tuning

Suhridk: /* Memory footprint tuning */

2013-12-08T18:02:31Z

Memory footprint tuning

Suhridk: Created page with "= Tuning = * Biggest contributor to latency is the Garbage Collector * Areas of Tuning : Memory, Lock Contention, CPU Usage, I/O * Areas of Memory Tuning: ** Memory footprint t..."

2013-12-08T17:59:25Z

Created page with "= Tuning = * Biggest contributor to latency is the Garbage Collector * Areas of Tuning : Memory, Lock Contention, CPU Usage, I/O * Areas of Memory Tuning: ** Memory footprint t..."

New page

= Tuning =

* Biggest contributor to latency is the Garbage Collector
* Areas of Tuning : Memory, Lock Contention, CPU Usage, I/O
* Areas of Memory Tuning:
** Memory footprint tuning
** Allocation rate tuning
** GC tuning

== Memory footprint tuning ==

* It's all about ensuring that the GC has less work to do
* One of the classic symptoms is the OutOfMemoryError
* Why ? It can be too much data, or the data representation is "fat", or there is a memory leak in the app code

← Older revision		Revision as of 18:35, 8 December 2013
Line 23:		Line 23:
	* JVM object header is two machine words. i.e. new Object() will consume 16 bytes on a 64 bit JVM		* JVM object header is two machine words. i.e. new Object() will consume 16 bytes on a 64 bit JVM
	* Simplest possible array decl : new byte[0] will take 24 bytes : 16 + 4 bytes (length) + 4 (round off to next multiple of 8)		* Simplest possible array decl : new byte[0] will take 24 bytes : 16 + 4 bytes (length) + 4 (round off to next multiple of 8)
		+	* e.g. avoid usage of primitive Wrappers.
		+	* Also not possible to know how the libraries we use are implemented - unless they are profiled.

← Older revision		Revision as of 18:20, 8 December 2013
Line 20:		Line 20:
	* If more memory can be added, add it.		* If more memory can be added, add it.
	* Do we actually need ALL that data in memory, consider using techniques such as LRU cache & Soft References		* Do we actually need ALL that data in memory, consider using techniques such as LRU cache & Soft References
		+	* Data representation itself
		+	* JVM object header is two machine words. i.e. new Object() will consume 16 bytes on a 64 bit JVM
		+	* Simplest possible array decl : new byte[0] will take 24 bytes : 16 + 4 bytes (length) + 4 (round off to next multiple of 8)

@@ Line 1: / Line 1: @@
 = Tuning =
-Notes from [http://www.infoq.com/presentations/JVM-Performance-Tuning-twitter]
+Notes from http://www.infoq.com/presentations/JVM-Performance-Tuning-twitter
 * Biggest contributor to latency is the Garbage Collector

← Older revision		Revision as of 18:13, 8 December 2013
Line 1:		Line 1:
	= Tuning =		= Tuning =
		+
		+	Notes from [http://www.infoq.com/presentations/JVM-Performance-Tuning-twitter]

	* Biggest contributor to latency is the Garbage Collector		* Biggest contributor to latency is the Garbage Collector

← Older revision		Revision as of 18:04, 8 December 2013
Line 16:		Line 16:
	* Look at the GC logs. Turn on the verbosegc option		* Look at the GC logs. Turn on the verbosegc option
	* Look at the Full GC messages : [Full GC $before->$after($total), $time secs]		* Look at the Full GC messages : [Full GC $before->$after($total), $time secs]
		+	* If more memory can be added, add it.
		+	* Do we actually need ALL that data in memory, consider using techniques such as LRU cache & Soft References

← Older revision		Revision as of 18:02, 8 December 2013
Line 13:		Line 13:
	* One of the classic symptoms is the OutOfMemoryError		* One of the classic symptoms is the OutOfMemoryError
	* Why ? It can be too much data, or the data representation is "fat", or there is a memory leak in the app code		* Why ? It can be too much data, or the data representation is "fat", or there is a memory leak in the app code
		+	* What is too much data ?
		+	* Look at the GC logs. Turn on the verbosegc option
		+	* Look at the Full GC messages : [Full GC $before->$after($total), $time secs]