CONCEVOIR UN SERVEUR
ULTRA-PERFORMANT EN JAVA :
L'EXPÉRIENCE DU PROJET
OPENDS
Ludovic Poitou
Friday, December 10, 2010
1

QUI SUIS-JE ?
• Ludovic
Poitou
• Product
Manager à ForgeRock
• Précédemment Architecte
chez Sun et “Community
Manager” pour le projet OpenDS
• Plus
de 14 ans d'expérience avec LDAP
• Architecte
de Sun Directory Server 5.2 / 6
2
• http://ludopoitou.wordpress.com
Friday, December 10, 2010
2

• ForgeRock AS
• Editeur
- Février 2010 - Norvège
de logiciels open source
• OpenAM
• ForgeRock
• Centre
(ex-OpenSSO), OpenIDM, OpenDJ (OpenDS) ...
France SAS - Novembre 2010
de Recherche & Développement à Grenoble
• UK, USA, Brésil, Allemagne, Suède...
Friday, December 10, 2010
3

AGENDA
• Une
présentation du projet OpenDS
• Modèles
de conceptions et réflexions sur la notion de
performance
• La
JVM et les performances
• Conclusion
Friday, December 10, 2010
4

LE PROJET OPENDS
• Lancé
en Open Source en July 2006
• CDDL
• Code
source : https://opends.dev.java.net/
• Sponsorisé
• Ecrit
par Sun Microsystems / Oracle
en Java par des experts LDAP
Friday, December 10, 2010
5

QU'EST CE ?
• OpenDS
est un server en Java qui implémente le protocol
LDAPv3 et ses services
• Il
inclut sa propre base de données,
• basé
• Pas
sur Berkeley DB Java Edition
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
Friday, December 10, 2010
6

POURQUOI FAIRE ?
• Stockage
• Pages
générique et orienté objet de données
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é
• Le
par l'infrastructure Web et Mail
fondement des produits de gestion d'Identité
• Gestion
Friday, December 10, 2010
d'Access, Fédération, Provisionnage
7

LES OBJECTIFS DU PROJET
OPENDS
• 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
• Capacité
aux standards et extensions LDAPv3
de croissance horizontale et verticale
• Utiliser
le code d'OpenDS pour le produit Oracle Directory
Server Enterprise Edition
Friday, December 10, 2010
8

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 !
Friday, December 10, 2010
9

OPENDS 2.2
• Disponible
• Un
depuis Décembre 2009
serveur d'annuaire 100% conforme à LDAPv3
• Nombreuses
• Réplication
données
• Fonctions
extensions LDAP standards et expérimentales
Multi Maitre, avec 3 niveaux de cohérence des
étendues de Sécurité
• S'installe
en 6 clics et moins de 3 minutes
• Gestion
par outils graphiques et textes
• Documentation
Friday, December 10, 2010
complète sur le Wiki
10

• Dérive
d’OpenDS
• Version
• Plus
2.4 la semaine prochaine
de 10 nouvelles fonctionnalités
• Un
grand nombre de correctifs
• De
meilleures performances
Friday, December 10, 2010
11

POUR QUI ?
• Les
opérateurs Télécom, le secteur financier, les portails
• Pour
• De
• Pour
stocker les identités des clients, téléphones et services
15 à 120 millions d'entrées, hautement disponibles
le service de Nommage, ou les PME
• OpenSolaris, Solaris, Linux..., couplé
avec Kerberos
• Pages
Friday, December 10, 2010
avec SAMBA, Intégré
blanches...
12

CARACTÉRISTIQUES DE
PERFORMANCES
• Comme
priment
• Jusqu'à
tout serveur, les capacités de montée en charge
plusieurs dizaines de millions d'entrées
• Plusieurs
• Quel
• Quel
Friday, December 10, 2010
milliers de connections
débit d'opérations?
Photo par Roger Smith http://www.flickr.com/photos/rogersmith/
temps de réponse moyen ? Maximum ?
13

ENVIRONNEMENT DE TEST
• OpenDS
• Le
2.2, Solaris 10, ZFS
test de base :
• 10
M d'entrées, taille moyenne 2,6K
• Réplication
Friday, December 10, 2010
multi-maitre entre 2 serveurs
14

LES RÉGLAGES DU TEST
• config.ldif
• ds-cfg-db-log-file-max: 100
MB
• ds-cfg-db-cache-percent: 70-80
• ds-cfg-db-checkpointer-bytes-interval: 100
MB
• ds-cfg-etime-resolution: nanoseconds
• ds-cfg-num-request-handlers: 4
• Replication
Friday, December 10, 2010
ON
15

SEARCHRATE SUR X4170
Friday, December 10, 2010
16

MODRATE SUR X4170
Friday, December 10, 2010
17

REFLEXIONS SUR LA
CONCEPTION
Photo par Jean-Pierre Dalbera http://www.flickr.com/people/dalbera/
Friday, December 10, 2010
18

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
Friday, December 10, 2010
19

PERFORMANCE VS
PARALLELISME
• Impact
des performances sur le parallelisme
• Code
sérialisé crée des points de contentions
• Manque
• Impact
de ressources
du parallelisme sur les performances
• L'utilisation
de plus de ressources conduit à plus de
contention et impacte les performances
• Réglage
Friday, December 10, 2010
du goulet d'étranglement
20

ATTENTION AUX SECTIONS
CRITIQUES
• Essayer
de minimiser le temps passé en section critique
• Mais
la bande passante est limitée par le temps passé dans la
plus grosse section critique
• Exemple
• 200
• 20
000 opérations sur processeur x64
000 sur processor T2000
• Utilisée
Friday, December 10, 2010
: LinkedBlockingQueue
pour la WorkQueue et les Access Logs
21

LE CACHE D'ENTRÉES
• Un
cache pour réduire les accès disques
• L'éviction
• Un
du cache rajoute du travail au GC
cache global est point de contention
• Cacher
uniquement des objets qui vont être réutilisés (et pas
peut-être)
• Utiliser
Friday, December 10, 2010
un cache “thread local”, mais attention aux coûts !
22

LE MONITORING DU SERVEUR
• Les
statistiques sont indispensables
• Mais
attention à la contention
• Ecritures
• Lecture
fréquentes (update stats)
beaucoup moins
• Une
stratégie est de garder des statistiques par thread et de
les collecter sur demande
• Pas
encore implémenté dans OpenDS !
Friday, December 10, 2010
23

PATTERNS
• Utilisation
des I/O asynchrones
• Utilisation
d'Objets Immuables
• Thread
• Less
code
• Utilisation
• Evite
• Avec
des “Static Factories” au lieu de Constructeurs
la création d'objets
• Permet
Friday, December 10, 2010
safe
des optimisations
des objet immuables.
24

PATTERNS
• Producteurs
/ Consommateurs
• Queues
• Pool
de Threads
• Monitors
Friday, December 10, 2010
25

ANTI-PATTERNS
• Manipulation
• Il
faut utiliser “StringBuilder”
• Le
compilateur optimise aussi “Aaa” + “Bbb”
• Eviter
• Ne
les grandes méthodes (Milliers de lignes de code)
pas exposer la représentation concrète d'un objet
• Set
• Ne
de chaines (String)
vs LinkedHashSet
pas définir plus de méthodes que nécessaires
Friday, December 10, 2010
26

COLLECTIONS JAVA
• Vector
et Hashtable sont synchronisés (toutes les méthodes)
=> Un cout à payer, même avec un seul thread
• Certaines
classes ne sont pas synchronisées par défaut
• ArrayList, LinkedList
• HashSet, HashMap
replacent Vector
replacent Hashtable
• Pour
synchroniser: Enrober dans une classe.
Par une méthode “static factory”
Collections.synchronizedList(new ArrayList())
• ConcurrentHashMap, pour
• Mais
Friday, December 10, 2010
la concurrence
attention à l'itérateur
27

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
Friday, December 10, 2010
de 10GB ethernet
28

LA JVM ET LES PARAMÈTRES
DES PERFORMANCES
“Tuning GC” est un art !
Photo par Kecko http://www.flickr.com/people/kecko/
Friday, December 10, 2010
29

GC DANS LA JVM HOTSPOT
•3
GCs disponibles:
• Serial
GC
• Parallel
GC / Parallel Old GC
• Concurrent
• Et
Mark-Sweep GC (CMS)
bientôt Garbage First (G1)
Friday, December 10, 2010
30

GESTION DU TAS
(POUR TOUS LES GCS)
Young Generation
Old Generation
Permanent Generation
Friday, December 10, 2010
31

YOUNG GENERATION
Allocation (new Object())
Eden
Friday, December 10, 2010
Survivor Spaces
32

OLD GENERATION
Promotion
(survivors from
the Young
Generation)
Friday, December 10, 2010
33

PERMANENT GENERATION
Permanent Generation
Allocation
(only directly from the JVM)
Friday, December 10, 2010
34

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
Photo par Craig Gorcott http://www.flickr.com/photos/craigweb/
• Malheureusement, vous
Friday, December 10, 2010
ne pouvez en choisir que 2 !
35

CONSEIL POUR REGLER LA
TAILLE DU TAS DE LA JVM
LE PLUS GROS POSSIBLE
Friday, December 10, 2010
36

UN EQUILIBRE A TROUVER
• Généralement, plus
• Valable
gros est l’espace mémoire, le mieux c’est !
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
Friday, December 10, 2010
37

L’IMPACT DES TAILLES DES
GENERATIONS
• 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
Friday, December 10, 2010
la fréquence des GCs majeurs le plus possible
38

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
Friday, December 10, 2010
39

REGLER LA “YOUNG
GENERATION”
Friday, December 10, 2010
40

DIMENSIONER LA TAILLE
MEMOIRE
• -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.
Friday, December 10, 2010
41

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)
Friday, December 10, 2010
42

DIMENSIONNER LES ESPACES
MEMOIRES
• -XX:NewSize=<size>
: Taille initiale de la “Young generation”
• -XX:MaxNewSize=<size>
generation”
• -XX:NewRatio=<ratio>
“old generation”
: Taille maximale de la “Young
: Ratio entre “young generation” et
• Pour
contrôler les performances, préférer -Xmn qui combine
-XX:NewSize et -XX:MaxNewSize
Friday, December 10, 2010
43

TENURING
• -XX:TargetSurvivorRatio=<%>, e.g., 50
• Pourcentage
• Laisser
d’occupation de l’espace “Survivor”
de l’espace pour gérer les pics
• -XX:InitialTenuringThreshold=<threshold>
• -XX:MaxTenuringThreshold=<threshold>
• -XX:+AlwaysTenure
• -XX:+NeverTenure
Friday, December 10, 2010
- Ne rien garder dans les “Survivor”
- Une très mauvaise idée
44

TENURING : AVANTAGES &
INCONVENIENTS
• 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
• Un
le cout des GCs mineurs
équilibre difficile à trouver
• Généralement, il
Friday, December 10, 2010
vaut mieux copier que promouvoir
45

GARBAGE FIRST
Friday, December 10, 2010
46

LE GC GARBAGE FIRST (G1)
• Nouveauté
de la VM Java HotSpot dans JDK 7
• Une
version experimentale de G1 est dans Java SE 6 depuis la
version mineur 14
• G1
est vu comme le replacement à long terme du GC
“Concurrent Mark-Sweep” (CMS)
• Toujours
Friday, December 10, 2010
expérimental dans Java SE 6 Update 23 ☹
47

CARACTERISTIQUES 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.
Friday, December 10, 2010
48

G1: LES OPTIONS DE LA JVM
• -XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC
• Temps
de pause (pas garanti, sinon utiliser Java Temps Réel)
• -XX:MaxGCPauseMillis=50
(objectif de 50 millisecondes)
• -XX:GCPauseIntervalMillis=1000
• Dimension:
(objectif de 1000 msecs)
-XX:+G1YoungGenSize=512m
• Parallélisme:
• -XX:+G1ParallelRSetUpdatingEnabled
• -XX:+G1ParallelRSetScanningEnabled
Friday, December 10, 2010
49

OPENDS ET CMS
• Les
options
• CMS
+ Occupency
• NewGenSize
= ¼ de la taille mémoire (jusqu’à 2GB)
• MaxTenuringThreshold
• Temps
• Mais
=1
de pause maximum GC mineur ~ 100ms
Full GC en écriture ! 10 seconds ☹
Friday, December 10, 2010
50

OPENDS ET G1
• Objectif: Eviter
• Collaboration
• OpenDS
• Entre
tests
le GC Complet, meilleur contrôle des pauses
entre les équipes HotSpot et OpenDS
est utilisé comme application de référence
20 et 30 améliorations integrées dans G1 suite aux
• Améliorations
par 10 des performances de G1 avec de
grandes zones mémoires
Friday, December 10, 2010
51

LE CONTROLE 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
• Peut
•A
est aussi un module extension de VisualVM
surveiller plusieurs VM dans le même outil
posteriori
• GC
Logging, PrintGCStats, GChisto
Friday, December 10, 2010
52

LE JOURNAL DU GC ACTIVÉ
EN PRODUCTION
• Activer
• Très
• Coût
le journal du GC en production sans crainte
utile pour analyser, diagnostiquer un problème
en performance extrêmement faible
• Peut-être
• Il
quelques gros fichiers à gérer
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!”
Friday, December 10, 2010
53

PARAMETRES POUR LE
JOURNAL DU GC
• -XX:+PrintGCTimeStamps
• Ajouter
-XX:+PrintGCDateStamps si besoin
• -XX:+PrintGCDetails
• Donne
• Mais
plus de détails que -verbosegc
aussi:
• -Xloggc:<fichier>
• Permet
de séparer les sorties du GC de celles de
l’application
Friday, December 10, 2010
54

PRINTGCSTATS
• Analyse
• Un
et résume les journaux du GC
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
Friday, December 10, 2010
55

PRINTGCSTATS PARALLEL GC
•
what
gen0t(s)
gen1t(s)
GC(s)
alloc(MB)
promo(MB)
used0(MB)
used1(MB)
used(MB)
commit0(MB)
commit1(MB)
commit(MB)
count
193
1
194
193
193
193
1
194
193
193
193
alloc/elapsed_time
alloc/tot_cpu_time
alloc/mut_cpu_time
promo/elapsed_time
promo/gc0_time
gc_seq_load
gc_conc_load
gc_tot_load
Friday, December 10, 2010
total
11.470
7.350
18.819
11244.609
807.236
16018.930
635.896
91802.213
17854.188
123520.000
141374.188
=
=
=
=
=
=
=
=
11244.609
11244.609
11244.609
807.236
807.236
301.110
0.000
301.110
mean
0.05943
7.34973
0.09701
58.26222
4.18257
82.99964
635.89648
473.20728
92.50874
640.00000
732.50874
MB
MB
MB
MB
MB
s
s
s
/
/
/
/
/
/
/
/
77.237
1235.792
934.682
77.237
11.470
1235.792
1235.792
1235.792
max
0.687
7.350
7.350
100.875
96.426
114.375
635.896
736.490
114.500
640.000
754.500
s
s
s
s
s
s
s
s
stddev
0.0633
0.0000
0.5272
18.8519
9.9291
17.4899
0.0000
87.8376
9.8209
0.0000
9.8209
= 145.586 MB/s
=
9.099 MB/s
= 12.030 MB/s
= 10.451 MB/s
= 70.380 MB/s
= 24.366%
=
0.000%
= 24.366%
56

PRINTGCSTATS CMS
•
what
gen0(s)
gen0t(s)
cmsIM(s)
cmsRM(s)
GC(s)
cmsCM(s)
cmsCP(s)
cmsCS(s)
cmsCR(s)
alloc(MB)
promo(MB)
used0(MB)
used(MB)
commit0(MB)
commit1(MB)
commit(MB)
count
110
110
3
3
113
3
6
3
3
110
110
110
110
110
110
110
alloc/elapsed_time
alloc/tot_cpu_time
alloc/mut_cpu_time
promo/elapsed_time
promo/gc0_time
gc_seq_load
gc_conc_load
gc_tot_load
Friday, December 10, 2010
total
24.381
24.397
0.285
0.092
24.774
2.459
0.971
14.620
0.036
11275.000
1322.718
12664.750
56546.542
12677.500
70400.000
83077.500
=
=
=
=
=
=
=
=
11275.000
11275.000
11275.000
1322.718
1322.718
396.378
18.086
414.464
mean
0.22164
0.22179
0.09494
0.03074
0.21924
0.81967
0.16183
4.87333
0.01200
102.50000
12.02471
115.13409
514.05947
115.25000
640.00000
755.25000
MB
MB
MB
MB
MB
s
s
s
/
/
/
/
/
/
/
/
83.621
1337.936
923.472
83.621
24.397
1337.936
1337.936
1337.936
max
1.751
1.751
0.108
0.032
1.751
0.835
0.191
4.916
0.016
102.500
104.608
115.250
640.625
115.250
640.000
755.250
s
s
s
s
s
s
s
s
stddev
0.2038
0.2038
0.0112
0.0015
0.2013
0.0146
0.0272
0.0638
0.0035
0.0000
11.8770
1.2157
91.5858
0.0000
0.0000
0.0000
= 134.835 MB/s
=
8.427 MB/s
= 12.209 MB/s
= 15.818 MB/s
= 54.217 MB/s
= 29.626%
=
1.352%
= 30.978%
57

GCHISTO
• Pour
une visualisation graphique des journaux du GC
• Développement
• Affiche
• Open
• Peut
démarré en 2008 (mais arrêté ?)
uniquement les temps de pause
source sur Java.net : http://gchisto.dev.java.net/
ne pas marcher avec certains paramètres du log du GC
Friday, December 10, 2010
58

EN RÉSUMÉ
• OpenDS: Un
serveur LDAP en Java, open source
• Simple
à installer et utiliser
• Conçu
pour de hautes performances et haute disponibilité
• OpenDJ
• Le
pour une version supportée (et améliorée)
paramètrage de la JVM et du GC est un Art
• L'ingénierie
des performances, un métier !
• Comprendre
• Qui
la JVM et les GCs est indispensable
a dit que Java est lent !
Friday, December 10, 2010
59

MAINTENANT...
• Essayez
OpenDJ:
• http://www.opendj.org
• IRC: #opendj
• Participez
Friday, December 10, 2010
on freenode.net
!
60

Concevoir un serveur
ultra-performant en Java :
l'expérience du projet OpenDS
• Ludovic
Poitou
• ludovic.poitou@ForgeRock.com
• Twitter: @LudoMP
• Blog: http://ludopoitou.wordpress.com
Friday, December 10, 2010
61