(codemotion 2014) jvm gc: wtf?!
DESCRIPTION
La máquina virtual y la plataforma Java se está convirtiendo en el pilar de multiples lenguajes: Java, Scala, Groovy, Clojure, Ceylon, JRuby... pero muchos desarrolladores no conocen como funciona por dentro tanto el sistema de memoria como el recolector de basura. Este conocimiento es fundamental y puede marcar la diferencia entre dos programadores. Esta charla consisitirá en una introducción a la gestión de memoria de la JVM (Hotspot), cómo trabaja el recolector de basura o algunas opciones para poder configurar las opciones por defecto. Si alguna vez te has cruzado con un OutOfMemoryError y no entendistes la línea que copiastes de StackOverflow: esta es tu charla.TRANSCRIPT
JVM GCWTF?!
Alonso Torres @alotor
Alonso Torres
@alotor @alotor
mobro.co/alotor
java.lang.OutOfMemoryError: unable to create new native thread
java.lang.OutOfMemoryError: Stack overflow
java.lang.OutOfMemoryError: PermGen space
java.lang.OutOfMemoryError: Metaspace
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.lang.OutOfMemoryError: requested... Out of swap space?
SUCCESS
No tengo memoria!!!
Todo va lento!!!!!!
El GC es ineficiente!!!!!
With CMS GC, the full collection is serial and STW, hence your application threads are stopped for the entire duration while the heap space is reclaimed and then compacted.
The duration for the STW pause depends on your heap size and the surviving objects.
http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All
Con el recolector CMS, la recolección es “serie” y STW, y los hilos de tu aplicación serán detenidos por la duración completa mientras el espacio del “heap” es recuperado y compactado.
La duración de la pausa STW dependerá del tamaño del “heap” y de los objetos supervivientes.
http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All
JVMJava Virtual Machine
GCGarbage Collectors
WTF?!Why They Fail?!
1. Estructura de la memoria
2. Conceptos generales de GC
3. Tipos de recolectores de Hotspot
4. Configuración de Hotspot
Os presento la
JVM
JVM PROCESS: 1.591 Gb
JVM PROCESS: 1.591 Gb
Memoria propia de la JVM
JVM PROCESS: 1.591 Gb
Memoria de ejecución
JVM PROCESS: 1.591 Gb
Memoria de datos
JVM PROCESS: 1.591 Gb
Memoria de clases
HEAP
- Bloque de memoria que la JVM se encargará de gestionar
- Almacena los datos de los objetos
- Memoria dinámica
LIBREOCUPADA
Max. Heap Size
LIBREOCUPADA
Max. Heap Size
LIBREOCUPADA
Max. Heap Size
LIBREOCUPADA
LIBREOCUPADA
AUMENTAMOS el heap
ó
LIBERAMOS memoria
OCUPADA LIBRE
OCUPADA LIBRE
Aumenta el heap
Liberamos el heap
¿Cómo liberamos la memoriaque ya no necesitamos?
1. Busca todos los objetos vivos
2. Libera la memoria de los objetos muertos
3. Mueve la posición de memoria de los vivos
Garbage Collection
- Serial Collector
- Parallel Collector
- CMS Collector
- G1
GC’s en OpenJDK Hotspot
- Serial Collector
- Parallel Collector
- CMS Collector
- G1
GC’s en OpenJDK Hotspot
MALDITOS TÉRMINOS!!
- Parada global de todos los hilos de ejecución para realizar recolección de basura
- El contrario puede ser CONCURRENTE○ La recolección se ejecuta a la vez que el
programa
Stop the World (STW)
STW Concurrente
● La ejecución se realiza en varios hilos de ejecución
● Aprovecha sistemas con múltiples CPUs
● Por contra puede ser SERIE○ Sólo se ejecutaría en un hilo
Paralelo
Paralelo Serie
● El trabajo de recolección no se realiza en un único paso sino en varias fases o pasos
● Por el contrario puede ser MONOLÍTICO○ Todo se ejecuta en un sólo paso
Incremental
Incremental Monolítico
- La mayoría de los objetos mueren jóvenes
- Los objetos viejos no suelen referenciar a objetos jóvenes
Weak Generational Hypothesis
Dos tipos de recolección:
○ 1 espacio pequeño con muchos muertos
○ 1 espacio grande donde casi todos vivos
Generational GC
Núm
ero
de o
bjet
os v
ivos
Número de objetos
TODOSlos GC’s son generacionales
YOUNG OLD/TENURE
Generational heap structure
SURVIVORS
OLD/TENUREEDEN
Generational heap structure
SURVIVORS
Recolectamos la Young Generation
Objetos promocionados van a supervivientes y a la Old Generation
La Old Generation está llena
Necesitamos una recolección completa
Empty young and survivors.
Free dead old-gen objects
● Serial Collector
● Parallel Collector
● CMS Collector
● G1 (Garbage First) Collector
GC’s en OpenJDK Hotspot
YOUNG GENERATION OLD GENERATION
Serial
Monolithic
Stop-The-World
Copying Mark / Sweep / Compact
Serial Collector
- Copia los objetos vivos de una región de la memoria a otra
- Libera la zona de memoria antigua
Algoritmo de COPIA (Scavenge)
Mark / Sweep / Compact (MSC)
1. Mark
2. Sweep
Mark / Sweep / Compact (MSC)
3. Compact
Mark / Sweep / Compact (MSC)
● Serial Collector
● Parallel Collector
● CMS Collector
● G1 (Garbage First) Collector
GC’s en OpenJDK Hotspot
Parallel Collector
YOUNG GENERATION OLD GENERATION
Paralelo Serie / Paralelo
Monolítico
Stop-The-World
Copying Mark / Sweep / Compact
● Serial Collector
● Parallel Collector
● CMS Collector
● G1 (Garbage First) Collector
GC’s en OpenJDK Hotspot
YOUNG GENERATION OLD GENERATION
Paralelo Serie Y Paralelo
Monolítico Incremental
Stop-The-World STW Y Concurrente
Copying Mark and Sweep
Concurrent Mark & Sweep
1. Initial Mark
2. Concurrent Mark
3. Remark
4. Concurrent Sweep
Concurrent Mark & Sweep
CMSNo compacta
CMS después de varias generaciones
Cuando hay excesiva
fragmentación
STW,Serial, Monolithic, MSC*
*AKA: Full GC
● Serial Collector
● Parallel Collector
● CMS Collector
● G1 (Garbage First) Collector
GC’s en OpenJDK Hotspot
- Retrasar al máximo un “Full GC”
- Baja latencia
- Predictibilidad
- Fácil de usar
Garbage First (G1)
- Divide el heap en regiones
- Libera primero las que tienen más basura (Garbage First)
- Compacta sobre la marcha
Garbage First (G1)
E O
O
E
O
O
O
S
G1 Heap Structure
E
1. Recolección de Young Collection
2. Marcado concurrente
3. Recolección mixta
4. Full GC
Garbage First (G1)
Young collection
E O
O
E E
O
O
O
E
Young collection
O
O
O
O
O
S
1. Recolección de Young Collection
2. Marcado concurrente
3. Recolección mixta
4. Full GC
Garbage First (G1)
Marcado concurrente
E O
O
O
O
O
E
O
O O
E S
Marcado concurrente
E O
O
E
X
O
X
O
O O
O
1. Recolección de Young Collection
2. Marcado concurrente
3. Recolección mixta
4. Full GC
Garbage First (G1)
Recolección mixta
E O
O
E
E X
O
X
E
O
O O
O
O
O
O
O
Recolección mixta
E O
O
E
E X
O
X
E
O
O O
O
O
O
O
O
Recolección mixta
O
O
O
X
O
O O
O
O
O
O
OS
1. Recolección de Young Collection
2. Marcado concurrente
3. Recolección mixta
4. Full GC
Garbage First (G1)
Todos los GC’s de Hotspottienen algún tipo de STW
STWes el mayor enemigo
del rendimiento
1. Maximizar recolección JOVEN
2. Minimizar los STW
3. Evitar objetos grandes
4. Evitar retención de objetos
Objetivos de optimización
Monitorizar la aplicación
-Xloggc:<file>
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
Opciones de monitorización
[GC [PSYoungGen: 578424K->8793K(630784K)]
1007570K->444386K(1155072K), 0.0185270 secs]
[Times: user=0.06 sys=0.00, real=0.02 secs]
[GC [PSYoungGen: 580697K->15128K(636928K)]
1016290K->459169K(1161216K), 0.0236090 secs]
[Times: user=0.08 sys=0.01, real=0.02 secs]
[GC [PSYoungGen: 450179K->6893K(635904K)]
894221K->465458K(1160192K), 0.0249430 secs]
[Times: user=0.07 sys=0.02, real=0.02 secs]
[Full GC [PSYoungGen: 6893K->0K(635904K)]
[ParOldGen: 458564K->454236K(816128K)] 465458K->454236K(1452032K)
[PSPermGen: 171991K->171852K(344064K)], 2.5341620 secs]
[Times: user=8.48 sys=0.01, real=2.53 secs]
[GC [PSYoungGen: 578424K->8793K(630784K)]
1007570K->444386K(1155072K), 0.0185270 secs]
[Times: user=0.06 sys=0.00, real=0.02 secs]
[GC [PSYoungGen: 580697K->15128K(636928K)]
1016290K->459169K(1161216K), 0.0236090 secs]
[Times: user=0.08 sys=0.01, real=0.02 secs]
[GC [PSYoungGen: 450179K->6893K(635904K)]
894221K->465458K(1160192K), 0.0249430 secs]
[Times: user=0.07 sys=0.02, real=0.02 secs]
[Full GC [PSYoungGen: 6893K->0K(635904K)]
[ParOldGen: 458564K->454236K(816128K)] 465458K->454236K(1452032K)
[PSPermGen: 171991K->171852K(344064K)], 2.5341620 secs]
[Times: user=8.48 sys=0.01, real=2.53 secs]
Recolección Young Generation
Full GC (STW)
YOUNG SURVIVORS OLD
Resumen del total
Análisis en detalle
jcmd pid GC.class_histogram
Herramientas
num #instances #bytes class name---------------------------------------------- 1: 762525 71798392 [C 2: 41739 68376080 [B 3: 675097 54007760 java.lang.reflect.Method 4: 404377 51770560 <methodKlass> 5: 404377 49495808 <constMethodKlass> 6: 864167 48393352 org.codehaus.groovy.runtime.metaclass. 7: 17110 29966392 <constantPoolKlass> 8: 710424 22733568 java.util.HashMap$Entry 9: 13777 18368640 <constantPoolCacheKlass> 10: 760859 18260616 java.lang.String 11: 507462 15419000 [Ljava.lang.Object; 12: 17104 14833688 <instanceKlassKlass> 13: 85375 12536048 [Lorg.codehaus.groovy.util.ComplexKeyHashMap$En 14: 303170 9701440 org.codehaus.groovy.util.SingleKeyHashMap$Entry 15: 386458 9274992 org.codehaus.groovy.util.FastArray 16: 50174 8596088 [Ljava.util.HashMap$Entry; 17: 333114 7010016 [Ljava.lang.Class;
jcmd pid GC.class_histogram
jcmd pid GC.heap_dump filename +jhat heapdumpfile
Herramientas
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=path
Herramientas
Configurar la JVM
-Xmx / -XmsTamaño máximo y mínimo del HEAP
-XX:MaxGCPauseMillis=nRecomendación de pausas
-XX:SurvivorRatio=nTamaño del espacio de supervivientes
Configuraciones
Tantas como para otra charla ;)
1. Estructura de la memoria
2. Conceptos generales de GC
3. Tipos de recolectores de Hotspot
4. Configuración de Hotspot
Con el recolector CMS, la recolección es “serie” y STW, y los hilos de tu aplicación serán detenidos por la duración completa mientras el espacio del “heap” es recuperado y compactado.
La duración de la pausa STW dependerá del tamaño del “heap” y de los objetos supervivientes.
http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All
No es tan fiero el lobo como lo pintan
Alonso Torres
@alotor @alotor
mobro.co/alotor
Bonus (post-presentación)
- Alternativas a JConsole○ VisualVM○ AppDynamics
- Para medir paradas del GC○ JHiccup http://www.azulsystems.com/product/jHiccup○ JMeter