1

Tél : +41 21 312 94 15 www.octo.com

© OCTO 2015

Avenue du théâtre 7 CH-1005 Lausanne - SUISSE

Comment ne plus ajouter de RAM à vos JVM sans savoir

pourquoi...

2

ANALYSE DE JVM LIVE

Agenda

2

ANALYSE DE DUMP 3

PRINCIPES DE GESTION DE MÉMOIRE EN JAVA 1

TAKE AWAY 4

3

Cette présentation est focalisée sur OpenJdk, les notions présentées restent cependant valables pour la JVM d’IBM

Pour des raisons de compréhension, certains mécanismes sont simplifiés…

Avant propos

4

Principes de gestion de mémoire en Java

Hypothèse générationnelle

Rappels

Les variations entre les versions de JVM

Déterminer qu’un objet est libérable

5

Principes de gestion de mémoire en Java

Rappels

6

Tous les objest sont alloués sur la heap   Pas d’allocation dans la stack, que des références

Chaque thread possède une thread local areas   Permet les allocations sans synchronisation   Sauf pour les objets de grande taille

Un objet ne peut pas être désaloué explicitement   C’est le GC – ou ramasse-miettes qui est en charge de ça

Allocations

7

Lorsqu’il n’est plus référencé (indirectement) par une racine (‘root’)   Il n’est plus possible d’obtenir une référence sur cet objet

Java n’utilise pas un mécanisme de compteur de références   Il n’y a pas de fuite mémoire technique possible

Quand un objet peut-il être nettoyé ?

8

Principes de gestion de mémoire en Java

Hypothèse générationnelle

9

La plupart des objets ne survivent pas longtemps   Il est plus efficace de rechercher prioritairement les objets à nettoyer parmi les jeunes objets   Les références des vieux objets vers les récents sont (relativement) peu nombreux

Hypothèse générationnelle (Java 1.4+)

nb instances

age / temps

10

3 memory pools

Young Generation

Old Generation

Perm

11

3 memory pools

Young Generation

Old Generation

Perm

1

12

3 memory pools

Young Generation

Old Generation

Perm

1

2

13

3 memory pools

Young Generation

Old Generation

Perm

1

2

3

14

(Quelques) options de la JVM

15

Principes de gestion de mémoire en Java

Déterminer qu’un objet est libérable

16

Les ‘strong references’ sont des ‘pointeurs’   Object a = b;

object.attribut = c

Mais aussi les autres types de référence (java.lang.ref.Reference) SoftReference, WeakReference, and PhantomReference

Références

17

Lorsqu’il n’est plus référencé (indirectement) par une racine (‘root’)

Java n’utilise pas un mécanisme de compteur de références   Il n’y a pas de fuite mémoire technique possible

Les racines sont constituées de tout ce qui permet d’atteindre un objet :   Des piles d’appels (stack)   Des registres CPU   Des références JNI   Classes chargées par le SystemClassLoader   Des autres Memory Pools

Tenured pour Young   Young pour Tenured

Quand un objet peut-il être nettoyé ?

18

Young Tenured

(1) (1) (6) (6)

Root

Références Cross Memory Pool

TenuringThreshold=6

19

Young Tenured

(1) (1) (6) (6)

Root

Minor GC

Références Cross Memory Pool

TenuringThreshold=6

20

Références Cross Memory Pool

TenuringThreshold=6

Young Tenured

(1) (1) (7) (7)

Root

(7) (7)

Minor GC

21

Young Tenured

(7) (7)

Root

(2) (2)

Références Cross Memory Pool

TenuringThreshold=6

22

Références Cross Memory Pool

Young Tenured

(7) (7)

Root

(2) (2)

X

23

Young Tenured

(7) (7)

Root

(2) (2)

X??

Minor GC

Références Cross Memory Pool

24

Young Tenured

(7) (7)

Root

(2) (2)

XRoot

Références Cross Memory Pool

25

La promotion précoce ou inutile d’objets en Tenured provoquera d’autres problèmes par la suite   Cela va faire augmenter les références entre la old génération et la young, ce qui est contraire aux hypothèses générationnelles

Mettre des références à null peut aider le collecteur à mieux libérer la mémoire   En restant raisonnable

Références Cross Memory Pool

26

Un GC survient   Lors d’un échec d’allocation

  La mémoire est pleine   La mémoire est trop fragmentée pour la taille souhaitée

  La mémoire atteint un seuil pour certain algorithme ( ≃92% pour CMS)   Un appel explicite à System.gc() (C’est le mal !)

  QQQ sun.rmi.dgc.client.gcInterval and sun.rmi.dgc.server.gcInterval.

Lors d’un GC, on parcours le graph des objets référencés par toutes les racines   Un partie de ce parcours est bloquant (stop-the-world)   Le SWAP de JVM durant un stop-the-world est dramatique

Fonctionnement - sommaire - des algorithmes Java

27

Le parcours de toutes les racines n’est pas efficace pour un Young GC   Ne passe pas l’échelle lorsque la taille de la JVM augmente

On utilise un mécanisme de ‘dirty cards’ pour limiter le parcours de la mémoire

Fonctionnement - sommaire - des algorithmes Java

0 reference card0

Eden S0 S1 TenuredB A

0 0 0 0 0 0 0 0 0 0

512

byte

s

0 reference card0

Eden S0 S1 TenuredB A

0 0 0 0 0 0 0 0 0

512

byte

s

01 0

28

Principes de gestion de mémoire en Java

Les variations entre les versions de JVM

29

Java 6 (6u45)   Décembre 2006 à Février 2013 (fin des mises à jour)

Java7 (7u80)   Juillet 2011 à Avril 2015

Java8 (8u60)   Mars 2014 à Septembre 2017 (?)

Java9   > Avril 2016

Les versions Java

30

Serial GC

Parallel GC

Parallel Old GC (Parallel Compacting GC)

Concurrent Mark & Sweep GC (or "CMS")

Garbage First (G1) GC

Les algorithmes en jdk 7/8

31

Remplacement de la PermGen par le MetaSpace   Similaire à JRockit et IBM   Décommissionnement PermGen (commencé en Java7)

MetaSpace en Native Memory => plus de limitation de taille   Le flag –XX:PermSize disparait

Introduction de G1 (Garbage-First Garbage)   Orienté faible pause STW (+6Go et moins 500ms de pause)   G1 fait de la défragmentation (compaction)

  CMS reste toujours meilleur pour les petites JVM   Par défaut à partir de Java 9 (JEP 248)

En Java 8

32

Organisation classique de la mémoire

Organisation de la mémoire G1

G1

33

Démo

34

Monitorer vos JVM   Live

Analyser vos traces GC   Analyser a posteriori l’évolution de la mémoire et des GC

Analyser vos dumps mémoire   Comprendre ce qui remplit votre JVM au runtime

Démo

35

JConsole ou VisualVM

Monitoring distant jdk/bin/jstatd -J-Djava.security.policy=security.policy

Demo Live Monitoring

grant codebase "file:${java.home}/../lib/tools.jar" { permission java.security.AllPermission;};

36

Identifier votre vrai problème [1/2]

Memory leak

37

Memory consumption

Identifier votre vrai problème [2/2]

38

-verbose:gc -Xloggc:/var/log/elasticsearch/gc.log   -XX:+UseGCLogFileRotation   -XX:NumberOfGCLogFiles=3   -XX:GCLogFileSize=200M

-XX:+PrintGCDetails -XX:+PrintTenuringDistribution -XX:+PrintGCCause -XX:+PrintGCApplicationStoppedTime

Ce sont des paramètres de production

Analyse : •  http://www.hp.com/go/java (free) •  https://github.com/chewiebug/GCViewer (free) •  http://www.jclarity.com/censum/ (payant)

Demo - Log GC

39

Dump en cas d’OutOfMemory   -XX:+HeapDumpOnOutOfMemoryError

Si vous avez des soucis avec la mémoire de vos JVM faites des heapdumps avant de les éteindre

sudo jmap -dump:file=memory.hprof -F $pid

Pour diminuer le temps de freeze de la JVM   sudo gcore -o jvm.hprof $pid ç bloquant mais rapide

sudo jmap -J-d64 -dump:live,file=jvm.hprof /usr/bin/java /tmp/jvm.core http://blogs.atlassian.com/2013/03/so-you-want-your-jvms-heap/

x

Dump mémoire

40

Dominator Tree

An object x dominates an object y if every path in the object graph from the start (or the root) node to y must go through x. The immediate dominator x of some object y is the dominator closest to the object y.

41

Take away

42

Pas d’optiomisation a priori   “Premature optimization is the root of all evil”

Measure Don’t Guess

Remettez vos habitudes en question   Les JVM ont évolué, des paramêtres utilisés sur de vieux Jdk n’ont plus de raison d’être

  Exemple : -Xms != -Xmx

Mettez à jour vos JVM

Mettez en place le monitoring distant jdk/bin/jstatd -J-Djava.security.policy=security.policy

Activer les traces sur vos JVM   Log GC

  -Xloggc:logs/gc-`date '+%Y%m%d-%H%M'`.log   -XX:+PrintGCDetails -XX:+PrintTenuringDistribution   -XX:+PrintGCCause -XX:+PrintGCApplicationStoppedTime   -Xloggc:/var/log/elasticsearch/gc.log

  -XX:+UseGCLogFileRotation   -XX:NumberOfGCLogFiles=3   -XX:GCLogFileSize=200M

  Analyse avec http://www.hp.com/go/java (free) ou http://www.jclarity.com/censum/ (payant)   -XX:+HeapDumpOnOutOfMemoryError   Faites des heapdumps avant d’éteindre vos JVM

sudo jmap -dump:file=memory.hprof -F $pid

Take away

grant codebase "file:${java.home}/../lib/tools.jar" { permission java.security.AllPermission;};

43

Tél : +41 21 312 94 15 www.octo.com

© OCTO 2015

Avenue du théâtre 7 CH-1005 Lausanne - SUISSE

+Philippe Kernevez @pkernevez pkernevez@octo.com

44

recrutement@octo.com

Vous croyez que les technologies changent le monde ?

Nous aussi ! Rejoignez-nous !

45

https://redstack.wordpress.com/2011/01/06/visualising-garbage-collection-in-the-jvm/ http://www.infoq.com/articles/Java_Garbage_Collection_Distilled http://www.cubrid.org/blog/dev-platform/understanding-java-garbage-collection/ https://dzone.com/articles/java-8-permgen-metaspace http://www.infoq.com/articles/Java-PERMGEN-Removed http://insightfullogic.com/2013/May/07/garbage-collection-java-3/ http://www.oracle.com/technetwork/tutorials/tutorials-1876574.html http://blogs.atlassian.com/2013/03/so-you-want-your-jvms-heap/

Crédits