Difference between revisions of "JVM Performance"
From Suhrid.net Wiki
Jump to navigationJump to search| (3 intermediate revisions by the same user not shown) | |||
| 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 | ||
| Line 18: | 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) | ||
| + | * e.g. avoid usage of primitive Wrappers. | ||
| + | * Also not possible to know how the libraries we use are implemented - unless they are profiled. | ||
Latest revision as of 11:35, 8 December 2013
Tuning
Notes from http://www.infoq.com/presentations/JVM-Performance-Tuning-twitter
- 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
- 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]
- 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
- 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)
- e.g. avoid usage of primitive Wrappers.
- Also not possible to know how the libraries we use are implemented - unless they are profiled.
