Slides de la présentation faite à Softshake 2015 ( http://soft-shake.ch ) "Les applications Java (et les autres langages de la JVM) consomment de plus en plus de mémoire, dans le même temps les algorithmes de GC (Garbage Collection) ont amélioré leur efficacité et permettent d’allouer toujours plus de mémoire. Malheureusement augmenter la RAM pour éviter une OutOfMemoryError sans plus d’investigation conduit souvent à masquer/repousser une fuite mémoire ou un bug applicatif et à générer une nouvelle source d’instabilité pour l’application et la JVM. Durant cette session nous verrons comment analyser la consommation mémoire d’une application afin de ne pas systématiquement lui accorder plus de mémoire sans savoir quel usage qui en est fait. Pour cela, nous commencerons par une rapide présentation du fonctionnement de la mémoire de la JVM puis nous verrons comment analyser la mémoire de vos applications en production. Cette deuxième partie sera faite de façon interactive sur une JVM issue d’un retour d’experience à l’aide de l’outil Eclipse Memory Analyzer. Nous terminerons avec quelques astuces pour vous aider lors de vos futures investigations."

1. 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. 2
ANALYSE DE JVM LIVE
Agenda
2
ANALYSE DE DUMP
3
PRINCIPES DE GESTION DE MÉMOIRE EN JAVA1
TAKE AWAY4

3. 3
Cette présentation est focalisée sur OpenJdk, les notions
présentées restent cependant valables pour
G1 (algorithme GC Java 8+)
La JVM d’IBM
Pour des raisons de compréhension, certains mécanismes sont
simplifiés…
Avant propos

4. 4
Principes de gestion de mémoire en Java

5. 5
La plupart des objets ne survivent pas longtemps
Il est plus efficace de rechercher prioritairement les objets à nettoyer
parmi les jeunes objets
Hypothèse générationnelle (Java 1.4+)
nb instances
age / temps

6. 6
3 memory pools
Young Generation
Old Generation
Perm

7. 7
3 memory pools
Young Generation
Old Generation
Perm
1

8. 8
3 memory pools
Young Generation
Old Generation
Perm
1
2

9. 9
3 memory pools
Young Generation
Old Generation
Perm
1
2
3

10. 10
Options de la JVM

11. 11
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
Des autres Memory Pools
Tenured pour Young
Young pour Tenured
Des ClassLoader
Avec les variables statiques
Quand un objet peut-il être nettoyé ?
La promotion précoce
d’objets en Tenured
provoquera d’autres
problèmes par la suite

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

13. 13
Young Tenured
(1) (1) (6) (6)
Root
Références Cross Memory Pool

14. 14
Young Tenured
(1) (1) (6) (6)
Root
Minor GC
Références Cross Memory Pool

15. 15
Young Tenured
(7) (7)
Root
(2) (2)
Références Cross Memory Pool

16. 16
Références Cross Memory Pool
Young Tenured
(7) (7)
Root
(2) (2)
X

17. 17
Young Tenured
(7) (7)
Root
(2) (2)
X
??
Minor GC
Références Cross Memory Pool

18. 18
Young Tenured
(7) (7)
Root
(2) (2)
X
Root
Références Cross Memory Pool

19. 19
La promotion précoce d’objets en Tenured provoquera d’autres
problèmes par la suite
Mettre des références à null aide le collecteur à mieux libérer la
mémoire
En restant raisonnable
Références Cross Memory Pool

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

21. 21
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 Tenured
B A
0 0 0 0 0 0 0 0 0 0
512bytes
0 reference card0
Eden S0 S1 Tenured
B A
0 0 0 0 0 0 0 0 0
512bytes
01 0

22. 22
Démo

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

24. 24
Identifier votre vrai problème [1/2]
Memory leak

25. 25
Memory consumption
Identifier votre vrai problème [2/2]

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

27. 27
Take away

28. 28
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
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;
};

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

30. 30
recrutement@octo.com
Vous croyez que les technologies changent le
monde ?
Nous aussi ! Rejoignez-nous !

31. 31
https://redstack.wordpress.com/2011/01/06/visualising-garbage-
collection-in-the-jvm/
http://www.infoq.com/articles/Java_Garbage_Collection_Distilled
Crédits