Difference between revisions of "JVM Performance"
From Suhrid.net Wiki
Jump to navigationJump to search (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...") |
|||
| 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] | ||
Revision as of 11:02, 8 December 2013
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
- 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]
