OpenDS - Ludovic Poitou - December 2010

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

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

3

AGENDA
• Une

présentation du projet OpenDS

• Modèles

de conceptions et réﬂexions sur la notion de
performance

• La

JVM et les performances

• Conclusion


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


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


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 Proﬁles 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

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


8

TROIS PRINCIPES
•

Facilité d'utilisation
•

•

Installation, Conﬁguration, Gestion, Surveillance...

Capacité d'extension
•
•

•

De nombreuses interfaces ont été déﬁnies
Avec des implémentations par défault

Performance
•

C'est le coeur de cette présentation !


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

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


11

POUR QUI ?
• Les

opérateurs Télécom, le secteur ﬁnancier, 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

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


milliers de connections

débit d'opérations?
Photo par Roger Smith http://www.ﬂickr.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


multi-maitre entre 2 serveurs

14

LES RÉGLAGES DU TEST
• conﬁg.ldif
• ds-cfg-db-log-ﬁle-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

ON
15

SEARCHRATE SUR X4170


16

MODRATE SUR X4170


17

REFLEXIONS SUR LA
CONCEPTION

Photo par Jean-Pierre Dalbera http://www.ﬂickr.com/people/dalbera/


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


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

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

: 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

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 !


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


safe

des optimisations

des objet immuables.
24

PATTERNS

• Producteurs

/ Consommateurs

• Queues
• Pool

de Threads

• Monitors


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éﬁnir plus de méthodes que nécessaires


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

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


de 10GB ethernet

28

LA JVM ET LES PARAMÈTRES
DES PERFORMANCES
“Tuning GC” est un art !

Photo par Kecko http://www.ﬂickr.com/people/kecko/


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)


30

GESTION DU TAS
(POUR TOUS LES GCS)
Young Generation
Old Generation

Permanent Generation


31

YOUNG GENERATION
Allocation (new Object())

Eden


Survivor Spaces

32

OLD GENERATION
Promotion
(survivors from
the Young
Generation)


33

PERMANENT GENERATION

Permanent Generation

Allocation
(only directly from the JVM)


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


ne pouvez en choisir que 2 !

35

CONSEIL POUR REGLER LA
TAILLE DU TAS DE LA JVM

LE PLUS GROS POSSIBLE

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


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

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


39

REGLER LA “YOUNG
GENERATION”


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.


41

DIMENSIONER LA “YOUNG
GENERATION”
• La

taille de l’Eden inﬂuence

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


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


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

- 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 difﬁcile à trouver

• Généralement, il

vaut mieux copier que promouvoir
45

GARBAGE FIRST


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


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.


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

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 ☹


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


51

LE CONTROLE DU GC
• En

direct:

• VisualVM: http://visualvm.dev.java.net/
• VisualGC:
Photo par Rennett Stowe http://www.ﬂickr.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


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 ﬁchiers à 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!”


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:<ﬁchier>
• Permet

de séparer les sorties du GC de celles de
l’application


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 ﬁle>

• 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


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

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

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
• Afﬁche
• 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


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 !


59

MAINTENANT...

• Essayez

OpenDJ:

• http://www.opendj.org
• IRC: #opendj
• Participez


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


61

OpenDS - Ludovic Poitou - December 2010

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (17)

Destaque

Destaque (20)

Semelhante a OpenDS - Ludovic Poitou - December 2010

Semelhante a OpenDS - Ludovic Poitou - December 2010 (20)

Mais de JUG Lausanne

Mais de JUG Lausanne (20)

OpenDS - Ludovic Poitou - December 2010