OOM m'a tuer - Devoxx France 2012

transcript

Renaud Bruyeron @brew_your_ownFrank Pavageau @fpavageau

OOM m’a tuer

Monday, April 23, 12

Agenda

1. La scène du crime

2. La gestion de la mémoire dans la JVM: les bases, les outils

3. Application

2Monday, April 23, 12

• Débuts au

• C -> Perl -> PHP -> Java

Renaud Bruyeron @brew_your_own

CTO d’

• Débuts au

• C -> Perl -> PHP -> Java

Renaud Bruyeron @brew_your_own

CTO d’

• C++ -> PHP -> Java

• Systèmes et devops

• Tech Lead socle eCommerce

Frank Pavageau @fpavageau

Architecte Senior

• C++ -> PHP -> Java

• Systèmes et devops

• Tech Lead socle eCommerce

Frank Pavageau @fpavageau

Architecte Senior

Une Plateforme webe-commerce B2C

•12+ Serveurs•10 Webapps différentes•50+ JVMs Oracle (JDK6)

•> 30000 sessions•250-400 Req/s•Variance très importante du trafic

... une victime un peu atypique...

Modélisation du catalogue sous forme de GrapheImplémentation custom du moteur de catalogue

100% sur la Heap (pas de BDD)Mise à jour par AtomicReference.set()

... une victime un peu atypique...

Modélisation du catalogue sous forme de GrapheImplémentation custom du moteur de catalogue

100% sur la Heap (pas de BDD)Mise à jour par AtomicReference.set()

Impossible de “cacher” aggressivementBeaucoup d’objets créés à chaque Request

Raccordements SI = latence = concurrence élevée

Débit Latence

Application interactive:Il faut privilégier les temps de réponse!

Le flagrant délit

Connections JDBC

Le flagrant délit

Connections JDBC

Requêtes/s

Le flagrant délit

Connections JDBC

Requêtes/s

Threads actifs

Le flagrant délit

Connections JDBC

Requêtes/s

Threads actifs

Requêtes en attente (Executor Queue Size)

l’explication

1 heure

l’explication

1 heure

On manque de recul: zoom arrière!

l’explication

24 heures

l’explication

24 heures

l’explication

24 heures

1 heure

l’explication

% de temps passé en GC

1 heure

The usual suspects...

• OutOfMemory Heap

• OutOfMemory PermGen

• Longues pauses de la JVM

➡ Sous forte charge = plantage assuré

le GC m’a

tuer!!Monday, April 23, 12

Mais ça sert à quoi alors le GC?

“Many concurrent algorithms are very easy to write with a GC and totally hard (to down right impossible) using explicit free.”

Cliff Click

OK, donc il suffit de régler quelques options...

664 options....

Source: Oracle JVM 1.6.0_31 x86_64 server

La mémoire dans la JVM

Permanent (PermGen) Metadata de classes,Strings internées, etc.

Permanent (PermGen)

Les objets

Metadata de classes,Strings internées, etc.

Young / New

Old / Tenured

Permanent (PermGen)

Old / Tenured

Eden S0 S1

Permanent (PermGen)

Approche générationelle du GC

Eden Sur

vivor 0

Surviv

Eden Sur

vivor 0

Surviv

Allocation

Eden Sur

vivor 0

Surviv

Eden Sur

vivor 0

Surviv

100% = GC!

Eden Sur

vivor 0

Surviv

RéférencéMort

Eden Sur

vivor 0

Surviv

Remise à zéro...

Eden Sur

vivor 0

Surviv

Eden Sur

vivor 0

Surviv

Allocation

Eden Sur

vivor 0

Surviv

100% = GC !

Eden Sur

vivor 0

Surviv

Eden Sur

vivor 0

Surviv

Eden Sur

vivor 0

Surviv

Remise à

Eden Sur

vivor 0

Surviv

Génération 1

Génération 2

Eden Sur

vivor 0

Surviv

Allocation

Eden Sur

vivor 0

Surviv

100% = GC !

Eden Sur

vivor 0

Surviv

Eden Sur

vivor 0

Surviv

Promotion

Old“Assez plein” = GC !

Compaction(optionnelle)

Garbage Collectors

•Générationnels

• Stop the world!

• Throughput ou Concurrent

Combinaisons de GCs

YoungYoung

OldOldOld

Serial Parallel

Serial

Parallel

Concurrent

Combinaisons de GCs

YoungYoung

OldOldOld

Serial Parallel

Serial Par défaut

Parallel N/A

Concurrent

Combinaisons de GCs

YoungYoung

OldOldOld

Serial Parallel

Serial

Parallel

Concurrent

Combinaisons de GCs

YoungYoung

OldOldOld

Serial Parallel

Serial

Parallel

Concurrent

Serial

Combinaisons de GCs

YoungYoung

OldOldOld

Serial Parallel

Serial

Parallel

Concurrent

Serial Parallel

Combinaisons de GCs

YoungYoung

OldOldOld

Serial Parallel

Serial

Parallel

Concurrent

Serial Parallel

ParallelOld

Combinaisons de GCs

YoungYoung

OldOldOld

Serial Parallel

Serial

Parallel

Concurrent

Serial Parallel

ParallelOld

Combinaisons de GCs

YoungYoung

OldOldOld

Serial Parallel

Serial

Parallel

Concurrent

Serial Parallel

ParallelOld

CMSCMS Serial

Combinaisons de GCs

YoungYoung

OldOldOld

Serial Parallel

Serial Serial Parallel

Parallel ParallelOld

Concurrent CMS Serial CMS

Les implémentations de Parallel diffèrent suivant les combinaisons

Comparatif des GCs

CMS est le bon compromis

Serial

Parallel

ParallelOld

CMS Serial

0 250 500 750 1000

Durée moyenne du test (s)

Les outils: CLI

jps, jhat, jmap, jstack, jstat

$ jstat -gcutil PID S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 40.88 58.41 18.34 66.65 2729 316.538 46 6.820 323.358

Les outils: GUIs

Les outils: GUIs (2)

•Un profiler

• Pendant le dev

• Pour les autopsies!

Les outils: GUIs (2)

•Un profiler

• Pendant le dev

• Pour les autopsies!

HeapDumpOnOutOfMemoryErrorHeapDumpPath

verbose:gc

Stop the world!

verbose:gc

Stop the world!

MBeans

OK, donc on sait mesurer... la température!

OK, donc on sait mesurer... la température !

59Credit: http://www.lhup.edu/mkhalequ/fieldtrip/geos253.htm

Problème : on ne peut pas faire un diagnostic avec une simple mesure...

Il faut historiser pour constituer un référentiel !

Donc il faut persister les mesures !

• JMX + jmxtrans

• RRD

• Graphite

• etc.

On peut modifier les réglages...

61Credit: http://www.our-energy.com

... si on sait mesurer/isoler les effets des réglages

Situation “avant”

Effet visible du tuning

Application et Résultats

Minimiser la fréquence et la durée des pauses de GC

Young (ParNew)Old (CMS-initial-mark + CMS-remark)

Tomcat

Application(code)

1. Le code

• Le tuning de JVM ne peut pas compenser du code de mauvaise qualité

• Des règles peuvent aider

• Privilégier les données immutables et donc réutilisables sans risque

• Sortir les invariants, notamment les instanciations, et surtout dans les boucles

• Connaitre les caractéristiques des structures de données des frameworks (java.util, Guava, Hibernate, etc.)

• Attention au rapport poids de la structure / poids des données

Exemple : HashMap

HashMap

Entry[16]

Exemple : HashMap

HashMap

Entry[16]

32Overhead = 160 Bytes!

Exemple : HashMap

HashMap

Entry[16]

32Overhead = 160 Bytes!

•SingletonMap (40 Bytes)•initialCapacity + loadFactor

Réduire les allocations...

... impacte la CPU

2. Tomcat

• Se méfier du pooling

• Les tags: enablePooling dans web/webdefault.xml

• -Dorg.apache.jasper.runtime.JspFactoryImpl.USE_POOL=false

• Attention aux buffers et à leur réutilisation

• -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true

• Le nombre de JSP impacte les besoins en PermGen

• Faire des tests et mesurer les impacts!

3. La JVM

pause > 1s !

3. La JVM

GC très fréquents

pause > 1s !

La heap

Heap-Xms : taille au démarrage

-Xmx : taille max

Young vs Old

-XX:NewSize -XX:MaxNewSize-XX:NewRatio

Young vs Old

Old•“Working Set”•Caches, Pools d’objets•HttpSession, objets de durée de vie intermédiaire

Objets < RequestScope

Young trop petite:

Young se remplit très vite = Beaucoup de GC Young

Promotion excessive d’objets en Old = Beaucoup de GC Old

Young trop grande:

Pauses de GC Young plus longues

Réglage de Young

NewRatio=8 pour -server sur Intel=

Trop peu de Young pour une webapp avec de la charge!

Réglage de Young

On augmente Young progressivement en mesurant les effets!

Old: attention à la fragmentation!

OldJDK6 < u22:

ParNew (prom

otion failur

e size = 155

95) (promoti

on failed)

Old generation : évolution idéale

Old generation : évolution réelle

Old generation : évolutions comparées

Accélérations

Contraintes supplémentaires

• Prise en compte des variations irrégulières

• Augmentation de trafic => augmentation de la pression mémoire

• Pour bien fonctionner, CMS doit avoir de la marge

• Plusieurs phases successives, la plupart concurrentes avec l’application=> le remplissage continue en même temps

Contraintes supplémentaires

• Prise en compte des variations irrégulières

• Augmentation de trafic => augmentation de la pression mémoire

• Pour bien fonctionner, CMS doit avoir de la marge

• Plusieurs phases successives, la plupart concurrentes avec l’application=> le remplissage continue en même temps

(concurrent mode failure): 2165740K->1284261K(2228224K), 8.9411250 secs

Marge de manoeuvre

CMSInitiatingOccupancyFraction = 92% par défaut

75-80% pour plus de marge

UseCMSInitiatingOccupancyOnly pour forcer le déclenchement uniquement sur ce critère!

Marge de manoeuvre

CMS initial-mark

CMS initial-mark (cumulé)

Mediane: -83%

Top 99%: -79%

CMS remark

CMS remark (cumulé)

Top 90%: -56%

Il reste des pauses !

• RMI (donc JMX) provoque des GC explicites à intervalles réguliers

• Appels à System.gc()

• GC explicite = Full GC (Serial) = pause de 4s !

• DisableExplicitGC + CMSClassUnloadingEnabled

• ExplicitGCInvokesConcurrentAndUnloadsClasses

Comparatif complet des GC

• Tuning des Survivors

• Taille, ratio de survivants, age maximum

• G1

• Principes et options complétement différents

• Autres JDKs : JRockit, Azul, IBM

• Vérifier les réglages à chaque changement applicatif

• Mesurer, mesurer, mesurer!

Et après?

Questions ?

OOM m'a tuer - Devoxx France 2012

Technology