Presentation sur le projet OpenDJ et les performances en Java. Contient une description du fonctionnement de la JVM Hotspot et des divers GC, y compris G1.
1. Concevoir un serveur
ultra-performant en Java :
l'expérience du projet
OpenDJ
Ludovic Poitou
Lyon JUG - 17/01/2012
(cc) 2012 ForgeRock
Wednesday, January 18, 12 1
2. Qui suis-je ?
- Ludovic Poitou
- Product Manager à ForgeRock
- Précédemment, Architecte chez Sun et
“Community Manager” pour le projet OpenDS
- Plus de 15 ans d'expérience avec LDAP
- Architecte de Sun Directory Server 5.2 / 6
- http://ludopoitou.wordpress.com
(cc) 2012 ForgeRock 2
Wednesday, January 18, 12 2
3. - ForgeRock AS - Février 2010 - Norvège
- Editeur de logiciels d’Infrastructure et Sécurité, open
source
- OpenAM (ex-OpenSSO), OpenDJ (OpenDS),
OpenICF, OpenIDM, OpenIG ...
- ForgeRock France SAS - Novembre 2010
- Centre de Recherche & Développement à Grenoble
- UK, USA, Brésil, Allemagne, Suède, Nouvelle Zélande...
(cc) 2012 ForgeRock
Wednesday, January 18, 12 3
4. Agenda
- Une présentation du project OpenDJ
- Performances et OpenDJ
- Performances et la JVM
- Conclusion
(cc) 2012 ForgeRock
Wednesday, January 18, 12 4
5. Le projet OpenDS
- Lancé en Open Source en July 2006
- CDDL
- Code source : https://opends.dev.java.net/
- Sponsorisé par Sun Microsystems
- Ecrit en Java par des experts LDAP
(cc) 2012 ForgeRock
Wednesday, January 18, 12 5
6. - Dérive d’OpenDS
- La seule branche activement développée en
open source
- Soutenue par la communauté
- Supporté par ForgeRock
(cc) 2012 ForgeRock
Wednesday, January 18, 12 6
7. Qu'est ce ?
- OpenDJ est un server en Java qui implémente le
protocol LDAPv3 et ses services
- Il inclut sa propre base de données,
- basé sur Berkeley DB Java Edition
- Pas accessible directement
- Possède toutes les fonctions de sécurité, de contrôle
d'accès, de gestion de mots de passes pour stocker
de façon sécurisée les identités des utilisateurs et
machines
(cc) 2012 ForgeRock
Wednesday, January 18, 12 7
8. Pourquoi Faire ?
- Stockage générique et orienté objet de données
- Pages blanches et carnet d'adresses mél
- Principalement le coffre fort des Identités
- Pour l'Authentication et les Authorizations
- Pour les Profiles et Personnalisations
- La brique de base de tout SI dans les entreprises
- Utilisé par l'infrastructure Web et Mail
- Le fondement des produits de gestion d'Identité
- Gestion d'Accès, Fédération, Provisionnage
(cc) 2012 ForgeRock
Wednesday, January 18, 12 8
9. Les Objectifs du Projet
OpenDJ
- Un jeu complet de Services d'Annuaire
- L'annuaire base de données, des services de Proxy
d'annuaire, des fonctions d'annuaire virtuel
- Conformes aux standards et extensions LDAPv3
- Capacité de croissance horizontale et verticale
- Remplacer Sun Directory Server Enterprise Edition
(cc) 2012 ForgeRock
Wednesday, January 18, 12 9
10. Trois Principes
- Facilité d'utilisation
- Installation, Configuration, Gestion, Surveillance...
- Capacité d'extension
- De nombreuses interfaces ont été définies
- Avec des implémentations par défault
- Performance
- C'est le coeur de cette présentation !
(cc) 2012 ForgeRock
Wednesday, January 18, 12 10
11. 2.4
- 2.4.0 en Decembre 2010, 2.4.4 en Octobre 2011
- Un serveur d'annuaire 100% conforme à LDAPv3
- Nombreuses extensions LDAP standards et
expérimentales
- Réplication Multi Maitre, avec 3 niveaux de
cohérence des données
- Fonctions étendues de Sécurité
- S'installe en 6 clics et moins de 3 minutes
- Gestion par outils graphiques et textes
- Documentation complète
(cc) 2012 ForgeRock
Wednesday, January 18, 12 11
12. Pour Qui ?
- Les opérateurs Télécom, le secteur financier, les portails
- Pour stocker les identités des clients, téléphones et
services
- De 15 à 120 millions d'entrées, hautement disponibles
- Pour le service de Nommage, ou les PME
- OpenSolaris, Solaris, Linux..., couplé avec SAMBA,
Intégré avec Kerberos
- Pages blanches...
(cc) 2012 ForgeRock
Wednesday, January 18, 12 12
13. Performances & OpenDJ
Photo by http://www.flickr.com/photos/nuonsolarteam
Photo by http://www.flickr.com/photos/ooocha/
(cc) 2012 ForgeRock
Wednesday, January 18, 12 13
14. Caractéristiques de
Performances
- Comme tout serveur, les capacités de
montée en charge priment
- Jusqu'à plusieurs dizaines de millions
d'entrées
- Plusieurs milliers de connections
- Quel débit d'opérations?
- Quel temps de réponse moyen ? Photo par Roger Smith http://www.flickr.com/photos/rogersmith/
Maximum ?
(cc) 2012 ForgeRock
Wednesday, January 18, 12 14
15. Environnement de Test
- OpenDS 2.2, Solaris 10, ZFS
- Le test de base :
- 10 M d'entrées, taille
moyenne 2,6K
- Réplication multi-maitre
entre 2 serveurs
(cc) 2012 ForgeRock
Wednesday, January 18, 12 15
16. Les réglages du Test
- 32GB JVM with tuning
- config.ldif
- ds-cfg-db-cache-percent: 70
- ds-cfg-etime-resolution: nanoseconds
- ds-cfg-num-request-handlers: 4
- Replication ON
(cc) 2012 ForgeRock
Wednesday, January 18, 12 16
23. Comment Obtenir de
Tels Résultats ?
- 2 Aspects
- Le code
- Le run-time : l'optimisation de la JVM et du
Garbage Collector
- Une relation très forte entre la conception du code
et la gestion mémoire
(cc) 2012 ForgeRock
Wednesday, January 18, 12 23
24. Attention aux Tests de
Performance
- Des tests reproductibles
- Maitrise du système et de l'environnement
- Avec 100 000 entrées LDAP lues par
seconde, le goulet peut être le réseau
- Utilisation de 10GB ethernet
(cc) 2012 ForgeRock
Wednesday, January 18, 12 24
25. La JVM et les
Performances
“Tuning GC” est un art !
Photo par Kecko http://www.flickr.com/people/kecko/
(cc) 2012 ForgeRock
Wednesday, January 18, 12 25
26. GC dans la VM
HotSpot
- 3 GCs disponibles:
- Serial GC
- Parallel GC / Parallel Old GC
- Concurrent Mark-Sweep GC (CMS)
- Et mainteant Garbage First (G1)
(cc) 2012 ForgeRock
Wednesday, January 18, 12 26
27. Gestion du Tas
(Pour Tous les GCs)
Young Generation
Old Generation
Permanent Generation
(cc) 2012 ForgeRock
Wednesday, January 18, 12 27
28. Young Generation
Allocation (new Object())
Eden Survivor Spaces
(cc) 2012 ForgeRock
Wednesday, January 18, 12 28
29. Old Generation
Promotion
(survivors from
the Young
Generation)
(cc) 2012 ForgeRock
Wednesday, January 18, 12 29
30. Permanent Generation
Permanent Generation
Allocation
(only directly from the JVM)
(cc) 2012 ForgeRock
Wednesday, January 18, 12 30
31. Le GC Rêvé
- Idéalement il faudrait un GC avec
- une faible consommation CPU,
- des temps de pauses infimes et
- efficace en occupation
mémoire
- Malheureusement, vous ne
pouvez en choisir que 2 !
Photo par Craig Gorcott http://www.flickr.com/photos/craigweb/
(cc) 2012 ForgeRock
Wednesday, January 18, 12 31
32. Conseil pour régler la
taille du tas de la JVM
LE PLUS GROS POSSIBLE
(cc) 2012 ForgeRock
Wednesday, January 18, 12 32
33. Un Equilibre à Trouver
- Généralement, plus gros est l’espace mémoire, le mieux!
- Valable pour les 2 espaces (Young Gen, Old Gen)
- Un grand espace = des GCs moins fréquents, moins
d’utilisation CPU, des objets qui sont vraiment détruits
- Un petit espace = des GCs plus rapide (pas toujours)
- Quelques fois, la taille maximale dépend de la mémoire
physique et/ou de l’espace d’adressage de la JVM
- Il faut trouver l'équilibre entre les tailles des
générations
(cc) 2012 ForgeRock
Wednesday, January 18, 12 33
34. L’Impact des Tailles des
Générations
- La taille de la “Young Generation”
- Détermine la fréquence des GCs mineurs
- Détermine combien d’objets vont être récoltés
- Ainsi que le “Tenuring Threshold” et la taille des
“Survivor Spaces”
- Old Generation
- Doit contenir les données permanentes de
l’application
- Réduire la fréquence des GCs majeurs le plus possible
(cc) 2012 ForgeRock
Wednesday, January 18, 12 34
35. 2 Points Très
Importants
- Essayer de maximiser le nombre d’objets
collectés dans la “Young generation”
- L’empreinte mémoire de l’application ne doit
pas dépasser la la taille de la mémoire
physique
- Ceci est valable quelque soit le GC
(cc) 2012 ForgeRock
Wednesday, January 18, 12 35
36. Régler la “Young
Generation”
(cc) 2012 ForgeRock
Wednesday, January 18, 12 36
37. Dimensioner la Taille
Mémoire
- -Xmx<size> : Taille mémoire max. (young + old
generation)
- -Xms<size> : Taille mémoire initiale (young + old
generation)
- -Xmn<size> : Taille mémoire pour la “Young generation”
- Pour contrôler les performances, il est préférable de
mettre -Xms and -Xmx à la même valeur
- Quand -Xms != -Xmx, l’accroissement ou diminution de
la mémoire nécessite un GC complet.
(cc) 2012 ForgeRock
Wednesday, January 18, 12 37
38. Dimensioner la “Young
Generation”
- La taille de l’Eden influence
- La fréquence des GCs mineurs
- Les objets qui seront réclamés à l’age 0
- Les objets alloué dans l’Eden ont un age 0
- L’age est incrémenté chaque GC mineur
- Augmenter la taille de l’Eden n’impact pas toujours la
durée des GCs mineurs : celle ci est proportionnelle
au nombre d’objets copiés (objets vivants)
(cc) 2012 ForgeRock
Wednesday, January 18, 12 38
39. Dimensionner les Espaces
Mémoires
- -XX:NewSize=<size> : Taille initiale de la “Young
generation”
- -XX:MaxNewSize=<size> : Taille maximale de la “Young
generation”
- -XX:NewRatio=<ratio> : Ratio entre “young
generation” et “old generation”
- Pour contrôler les performances, préférer -Xmn qui
combine
-XX:NewSize et -XX:MaxNewSize
(cc) 2012 ForgeRock
Wednesday, January 18, 12 39
40. Tenuring
- -XX:TargetSurvivorRatio=<%>, e.g., 50
- Pourcentage d’occupation de l’espace “Survivor”
- Laisser de l’espace pour gérer les pics
- -XX:InitialTenuringThreshold=<threshold>
- -XX:MaxTenuringThreshold=<threshold>
- -XX:+AlwaysTenure - Ne rien garder dans les
“Survivor”
- -XX:+NeverTenure - Une très mauvaise idée
(cc) 2012 ForgeRock
Wednesday, January 18, 12 40
41. Tenuring : Avantages &
Inconvénients
- Maintenir le plus d’objets dans les espaces “Survivor”
pour qu’ils soient collectés dans la “Young generation”
- Moins de promotion vers la “Old generation”
- Moins de GCs de la “Old generation”
- Mais éviter les nombreuses copies entre espaces
“Survivor”
- Augmente le cout des GCs mineurs
- Un équilibre difficile à trouver
- Généralement, il vaut mieux copier que promouvoir
(cc) 2012 ForgeRock
Wednesday, January 18, 12 41
42. Garbage First
(cc) 2012 ForgeRock
Wednesday, January 18, 12 42
43. LE GC Garbage First
(G1)
- Nouveauté de la JVM HotSpot dans JDK 7
- Le replacement à long terme du GC
“Concurrent Mark-Sweep” (CMS)
- Objectif : plus de “Stop the World” GC !
- Version expérimentale de G1 dans Java SE 6
depuis la version mineur 14
- Utilisable avec Java 7u2
(cc) 2012 ForgeRock
Wednesday, January 18, 12 43
44. Caractèristiques de G1
- Le remplacement de CMS
- Un GC pour les Serveurs
- Parallèle, Concurrent
- S’appuie sur des Générations
- Auto Compactant
- Facile d’utilisation
- Prédictif (mais pas temps réel)
- Les étapes principales sont: remembered set (RS)
maintenance, concurrent marking, and evacuation
pauses.
(cc) 2012 ForgeRock
Wednesday, January 18, 12 44
45. G1: Les Options de la
JVM
- -XX:+UseG1GC
(-XX:+UnlockExperimentalVMOptions)
- Temps de pause (pas garanti, sinon utiliser Java Temps Réel)
- -XX:MaxGCPauseMillis=50 (objectif de 50 millisecondes)
- -XX:GCPauseIntervalMillis=1000 (objectif de 1000 msecs)
- Taille des régions: -XX:G1HeapRegionSize=4M (de 1 a 32M)
(cc) 2012 ForgeRock
Wednesday, January 18, 12 45
46. OpenDJ et CMS
- Les options
- CMS + Occupency
- NewGenSize = ¼ de la taille mémoire (jusqu’à
2GB)
- MaxTenuringThreshold = 1
- Temps de pause maximum GC mineur ~ 100ms
- Mais Full GC en écriture ! > 10 seconds ☹
(cc) 2012 ForgeRock
Wednesday, January 18, 12 46
47. OpenDS et G1
- Objectif: Eviter le GC Complet, meilleur contrôle des
temps de pause
- Collaboration entre les équipes Sun HotSpot et OpenDS
- OpenDS est utilisé comme application de référence
- + de 20 améliorations integrées dans G1 suite aux tests
- Améliorations par 10 des performances de G1 avec de
grandes zones mémoires
(cc) 2012 ForgeRock
Wednesday, January 18, 12 47
48. OpenDJ, G1 et Java 7u2
- export OPENDS_JAVA_ARGS="-server -Xmx2G -Xms2G -Xmn512M -XX:+UseG1GC -
XX:MaxGCPauseMillis=10 -XX:G1HeapRegionSize=4M -XX:MaxTenuringThreshold=1 -XX:
+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+UseCompressedOops"
- Modrate, TEMPFS:
G1:
16676.3 16373.0 1.916 1.952 18.973 28.206 59.249 0.0
16305.4 16372.4 1.960 1.952 18.966 28.160 57.163 0.0
16695.9 16375.1 1.911 1.951 18.941 28.123 59.249 0.0
16463.6 16375.8 1.943 1.951 18.927 28.104 59.924 0.0
CMS:
18041.9 17471.3 1.770 1.829 18.236 30.057 117.356 0.0
- G1 consomme plus de CPU, mais est plus prédictif
- Reste à tester avec de grosses JVM (16 à 64 GB)
- G1 enfin utilisable avec Java 7u2
(cc) 2012 ForgeRock
Wednesday, January 18, 12 48
49. Le Contrôle du GC
- En direct:
- VisualVM: http://visualvm.dev.java.net/
- VisualGC:
Photo par Rennett Stowe http://www.flickr.com/photos/tomsaint/
- http://java.sun.com/performance/jvmstat/
- VisualGC est aussi un module extension de VisualVM
- Peut surveiller plusieurs VM dans le même outil
- A posteriori
- GC Logging, PrintGCStats
(cc) 2012 ForgeRock
Wednesday, January 18, 12 49
50. Le Journal du GC
Activé en Production
- Activer le journal du GC en production sans crainte
- Très utile pour analyser, diagnostiquer un problème
- Coût en performance extrêmement faible
- Peut-être quelques gros fichiers à gérer
- Il y a toujours des clients qui ont peur d’activer les logs
- Un (gros) client de Sun a dit : “If someone doesn't enable
GC logging in production, I shoot them!”
(cc) 2012 ForgeRock
Wednesday, January 18, 12 50
51. Paramètres pour le
Journal du GC
- -XX:+PrintGCTimeStamps
- Ajouter -XX:+PrintGCDateStamps si besoin
- -XX:+PrintGCDetails
- Donne plus de détails que -verbosegc
- Mais aussi:
- -Xloggc:<fichier>
- Permet de séparer les sorties du GC de celles de
l’application
(cc) 2012 ForgeRock
Wednesday, January 18, 12 51
53. PrintGCStats
- Analyse et résume les journaux du GC
- Un script disponible
- http://java.sun.com/developer/technicalArticles/
Programming/turbo/PrintGCStats.zip
- Usage
- PrintGCStats -v cpus=<num> <gc log file>
- Ou <num> est le nombre de CPU de la machine qui a
produit les logs.
- Peut ne pas marcher avec certains paramètres du log du GC
(cc) 2012 ForgeRock
Wednesday, January 18, 12 53
56. En Résumé
- OpenDJ: Un serveur LDAP en Java, open source
- Simple à installer et utiliser
- Conçu pour de hautes performances et haute disponibilité
- OpenDJ pour une version supportée (et améliorée)
- Le paramètrage de la JVM et du GC est un Art
- L'ingénierie des performances, un métier !
- Comprendre la JVM et les GCs est indispensable
- Qui a dit que Java est lent !
(cc) 2012 ForgeRock
Wednesday, January 18, 12 56