OOM m'a tuer - Devoxx France 2012

Renaud Bruyeron @brew_your_ownFrank Pavageau @fpavageau

1

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

3

CTO d’


• Débuts au

• C -> Perl -> PHP -> Java

Renaud Bruyeron @brew_your_own

3

CTO d’


• C++ -> PHP -> Java

• Systèmes et devops

• Tech Lead socle eCommerce

Frank Pavageau @fpavageau

4

Architecte Senior


• C++ -> PHP -> Java

• Systèmes et devops

• Tech Lead socle eCommerce

Frank Pavageau @fpavageau

4

Architecte Senior


5

Apa

che

Tom

cat

Ora

cle

Une Plateforme webe-commerce B2C


5

Apa

che

Tom

cat

Ora

cle


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


5

Apa

che

Tom

cat

Ora

cle


•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...

6

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...

6

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


7

vs.

Débit Latence



8

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


Le flagrant délit

9

Temps

Connections JDBC


Le flagrant délit

9

Temps

Connections JDBC

Temps

Requêtes/s


Le flagrant délit

9

Temps

Connections JDBC

Temps

Requêtes/s

Temps

Threads actifs


Le flagrant délit

9

Temps

Connections JDBC

Temps

Requêtes/s

Temps

Threads actifs

Temps

Requêtes en attente (Executor Queue Size)


l’explication

10

Taill

e en

MB

1 heure

Heap


l’explication

10

Taill

e en

MB

1 heure

Heap

On manque de recul: zoom arrière!


l’explication

11

Taill

e en

MB

24 heures

Heap


l’explication

11

Taill

e en

MB

24 heures

Heap


l’explication

11

Taill

e en

MB

24 heures

Heap


0

25

50

75

100

1 heure

l’explication

12

% de temps passé en GC

Taill

e en

MB

1 heure

Heap


The usual suspects...



• OutOfMemory Heap




• OutOfMemory PermGen





• Longues pauses de la JVM






➡ Sous forte charge = plantage assuré



















13

le GC m’a

tuer!!Monday, April 23, 12

Mais ça sert à quoi alors le GC?

14

“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...


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

15

664 options....

Source: Oracle JVM 1.6.0_31 x86_64 server




JVM

La mémoire dans la JVM

17


JVM

18

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


Heap

19

Permanent (PermGen)

Les objets

Metadata de classes,Strings internées, etc.


20

Young / New

Old / Tenured

Permanent (PermGen)


21

Old / Tenured

Eden S0 S1

Permanent (PermGen)


Approche générationelle du GC

22

Old

Eden Sur

vivor 0

Surviv

or 1


23

Old

Eden Sur

vivor 0

Surviv

or 1

Allocation


24

Old

Eden Sur

vivor 0

Surviv

or 1


25

Old

Eden Sur

vivor 0

Surviv

or 1

100% = GC!


26

Old

Eden Sur

vivor 0

Surviv

or 1

RéférencéMort


27

Old

Eden Sur

vivor 0

Surviv

or 1

Copie


Remise à zéro...

28

Old

Eden Sur

vivor 0

Surviv

or 1


29

Old

Eden Sur

vivor 0

Surviv

or 1

Allocation


30

Old

Eden Sur

vivor 0

Surviv

or 1

100% = GC !


31

Old

Eden Sur

vivor 0

Surviv

or 1


32

Old

Eden Sur

vivor 0

Surviv

or 1

Copie


33

Old

Eden Sur

vivor 0

Surviv

or 1

Copie


34

Remise à

Old

zéro

Eden Sur

vivor 0

Surviv

or 1

Génération 1

Génération 2


35

Old

Eden Sur

vivor 0

Surviv

or 1

Allocation


36

Old

Eden Sur

vivor 0

Surviv

or 1

100% = GC !


37

Old

Eden Sur

vivor 0

Surviv

or 1

Copie


38

Eden Sur

vivor 0

Surviv

or 1

Promotion

Old


Old


40

Old“Assez plein” = GC !




43

Old

Compaction(optionnelle)



Garbage Collectors

45

•Générationnels

• Stop the world!

• Throughput ou Concurrent


Combinaisons de GCs

46

YoungYoung

OldOldOld

Serial Parallel

Serial

Parallel

Concurrent


Combinaisons de GCs

47

YoungYoung

OldOldOld

Serial Parallel

Serial Par défaut

Parallel N/A

Concurrent


Combinaisons de GCs

48

YoungYoung

OldOldOld

Serial Parallel

Serial

Parallel

Concurrent


Combinaisons de GCs

48

YoungYoung

OldOldOld

Serial Parallel

Serial

Parallel

Concurrent

Serial


Combinaisons de GCs

48

YoungYoung

OldOldOld

Serial Parallel

Serial

Parallel

Concurrent

Serial Parallel


Combinaisons de GCs

48

YoungYoung

OldOldOld

Serial Parallel

Serial

Parallel

Concurrent

Serial Parallel

ParallelOld


Combinaisons de GCs

48

YoungYoung

OldOldOld

Serial Parallel

Serial

Parallel

Concurrent

Serial Parallel

ParallelOld

CMS


Combinaisons de GCs

48

YoungYoung

OldOldOld

Serial Parallel

Serial

Parallel

Concurrent

Serial Parallel

ParallelOld

CMSCMS Serial


Combinaisons de GCs

49

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


Comparatif des GCs


CMS est le bon compromis

51

Serial

Parallel

ParallelOld

CMS

CMS Serial

0 250 500 750 1000

937

871

846

852

917

Durée moyenne du test (s)


Les outils: CLI

52

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!

54

HeapDumpOnOutOfMemoryErrorHeapDumpPath


verbose:gc


verbose:gc


verbose:gc


verbose:gc


verbose:gc


verbose:gc


verbose:gc


verbose:gc

55

Stop the world!


verbose:gc

55

Stop the world!


MBeans


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


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

58

=


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 !


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


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

62

Situation “avant”

Effet visible du tuning

cput

ime


Application et Résultats


64

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

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


65

vs.


JVM

Tomcat

65

Application(code)

vs.


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

67

HashMap

Entry[16]

Entry

value

key

48

80

32


Exemple : HashMap

67

HashMap

Entry[16]

Entry

value

key

48

80

32Overhead = 160 Bytes!


Exemple : HashMap

67

HashMap

Entry[16]

Entry

value

key

48

80

32Overhead = 160 Bytes!

•SingletonMap (40 Bytes)•initialCapacity + loadFactor


Réduire les allocations...

68

GC

You

ng /

s


... impacte la CPU

69

Cha

rge

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

71

Hea

p Si

ze

Time

Hea

p Si

ze

Time


3. La JVM

71

Hea

p Si

ze

Time

Hea

p Si

ze

Time

pause > 1s !


3. La JVM

71

Hea

p Si

ze

Time

Hea

p Si

ze

Time

GC très fréquents

pause > 1s !


La heap

72

Heap


La heap

72

Heap-Xms : taille au démarrage

-Xmx : taille max


Young vs Old

73

Young

Old


Young vs Old

73

Young

Old

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


Young vs Old

73

Young

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

Objets < RequestScope


Young trop petite:

74

Young

Old


Young trop petite:

74

Young

Old

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

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


Young trop grande:

75

Young

Old


Young trop grande:

75

Young

Old

Pauses de GC Young plus longues


Réglage de Young

76

Young

Old

NewRatio=8 pour -server sur Intel=

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


Réglage de Young

76

Young

Old

On augmente Young progressivement en mesurant les effets!


Old: attention à la fragmentation!

77

Young

Old


Old: attention à la fragmentation!

77

Young

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


Old generation : évolutions comparées

80

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

81

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


Marge de manoeuvre

82

Young

Old


Marge de manoeuvre

82

Young

Old

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

82

Young

Old


83

CMS initial-mark


84

CMS initial-mark (cumulé)


84


Mediane: -83%


84


Mediane: -83%

Top 99%: -79%


85

CMS remark


86

CMS remark (cumulé)


86

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!

90

Et après?


91

Questions ?


Date post:	01-Jul-2015
Category:	Technology
Upload:	ekino
View:	6,929 times
Download:	1 times

OOM m'a tuer - Devoxx France 2012

Technology