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...
• ForgeRock AS
• Editeur

- Février 2010 - Norvège

de logiciels open source

• OpenAM
• ForgeRock
• Centre

(ex-OpenSSO),...
AGENDA
• Une

présentation du projet OpenDS

• Modèles

de conceptions et réflexions sur la notion de
performance

• La

JV...
LE PROJET OPENDS
• Lancé

en Open Source en July 2006

• CDDL
• Code

source : https://opends.dev.java.net/

• Sponsorisé
...
QU'EST CE ?
• OpenDS

est un server en Java qui implémente le protocol
LDAPv3 et ses services

• Il

inclut sa propre base...
POURQUOI FAIRE ?
• Stockage
• Pages

générique et orienté objet de données

blanches et carnet d'adresses mél

• Principal...
LES OBJECTIFS DU PROJET
OPENDS
• Un

jeu complet de Services d'Annuaire

• L'annuaire

base de données, des services de Pr...
TROIS PRINCIPES
•

Facilité d'utilisation
•

•

Installation, Configuration, Gestion, Surveillance...

Capacité d'extension...
OPENDS 2.2
• Disponible
• Un

depuis Décembre 2009

serveur d'annuaire 100% conforme à LDAPv3

• Nombreuses
• Réplication
...
• Dérive

d’OpenDS

• Version
• Plus

2.4 la semaine prochaine

de 10 nouvelles fonctionnalités

• Un

grand nombre de cor...
POUR QUI ?
• Les

opérateurs Télécom, le secteur financier, les portails

• Pour
• De
• Pour

stocker les identités des cli...
CARACTÉRISTIQUES DE
PERFORMANCES
• Comme

priment

• Jusqu'à

tout serveur, les capacités de montée en charge
plusieurs di...
ENVIRONNEMENT DE TEST

• OpenDS
• Le

2.2, Solaris 10, ZFS

test de base :

• 10

M d'entrées, taille moyenne 2,6K

• Répl...
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-checkpoin...
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, 201...
COMMENT OBTENIR DE TELS
RÉSULTATS ?
• 2 Aspects
• Le

code

• Le

run-time : l'optimisation de la JVM et du Garbage
Collec...
PERFORMANCE VS
PARALLELISME
• Impact

des performances sur le parallelisme

• Code

sérialisé crée des points de contentio...
ATTENTION AUX SECTIONS
CRITIQUES
• Essayer

de minimiser le temps passé en section critique

• Mais

la bande passante est...
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...
LE MONITORING DU SERVEUR
• Les

statistiques sont indispensables

• Mais

attention à la contention

• Ecritures
• Lecture...
PATTERNS
• Utilisation

des I/O asynchrones

• Utilisation

d'Objets Immuables

• Thread
• Less

code

• Utilisation
• Evi...
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...
COLLECTIONS JAVA
• Vector

et Hashtable sont synchronisés (toutes les méthodes)
=> Un cout à payer, même avec un seul thre...
ATTENTION AUX TESTS DE
PERFORMANCE
• Des

tests reproductibles

• Maitrise

du système et de l'environnement

• Avec

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

Photo par Kecko http://www.flickr.com/people/kecko/

Fr...
GC DANS LA JVM HOTSPOT

•3

GCs disponibles:

• Serial

GC

• Parallel

GC / Parallel Old GC

• Concurrent
• Et

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

• effic...
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 (Yo...
L’IMPACT DES TAILLES DES
GENERATIONS
• La

taille de la “Young Generation”

• Détermine

la fréquence des GCs mineurs

• D...
2 POINTS TRÈS IMPORTANTS
• Essayer

de maximiser le nombre d’objets collectés dans la
“Young generation”

• L’empreinte

m...
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...
DIMENSIONER LA “YOUNG
GENERATION”
• La

taille de l’Eden influence

• La

fréquence des GCs mineurs

• Les

objets qui sero...
DIMENSIONNER LES ESPACES
MEMOIRES
• -XX:NewSize=<size>

: Taille initiale de la “Young generation”

• -XX:MaxNewSize=<size...
TENURING
• -XX:TargetSurvivorRatio=<%>, e.g., 50
• Pourcentage
• Laisser

d’occupation de l’espace “Survivor”

de l’espace...
TENURING : AVANTAGES &
INCONVENIENTS
• Maintenir

le plus d’objets dans les espaces “Survivor” pour
qu’ils soient collecté...
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 S...
CARACTERISTIQUES DE G1
• Le

remplacement de CMS

• Un

GC pour les Serveurs

• Parallèle, Concurrent
• S’appuie

sur des ...
G1: LES OPTIONS DE LA JVM
• -XX:+UnlockExperimentalVMOptions

-XX:+UseG1GC

• Temps

de pause (pas garanti, sinon utiliser...
OPENDS ET CMS
• Les

options

• CMS

+ Occupency

• NewGenSize

= ¼ de la taille mémoire (jusqu’à 2GB)

• MaxTenuringThres...
OPENDS ET G1
• Objectif: Eviter
• Collaboration
• OpenDS
• Entre

tests

le GC Complet, meilleur contrôle des pauses

entr...
LE CONTROLE DU GC
• En

direct:

• VisualVM: http://visualvm.dev.java.net/
• VisualGC:
Photo par Rennett Stowe http://www....
LE JOURNAL DU GC ACTIVÉ
EN PRODUCTION
• Activer
• Très
• Coût

le journal du GC en production sans crainte

utile pour ana...
PARAMETRES POUR LE
JOURNAL DU GC
• -XX:+PrintGCTimeStamps
• Ajouter

-XX:+PrintGCDateStamps si besoin

• -XX:+PrintGCDetai...
PRINTGCSTATS
• Analyse
• Un

et résume les journaux du GC

script disponible

• http://java.sun.com/developer/technicalArt...
PRINTGCSTATS PARALLEL GC
•

what
gen0t(s)
gen1t(s)
GC(s)
alloc(MB)
promo(MB)
used0(MB)
used1(MB)
used(MB)
commit0(MB)
comm...
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)
...
GCHISTO
• Pour

une visualisation graphique des journaux du GC

• Développement
• Affiche
• Open
• Peut

démarré en 2008 (m...
EN RÉSUMÉ
• OpenDS: Un

serveur LDAP en Java, open source

• Simple

à installer et utiliser

• Conçu

pour de hautes perf...
MAINTENANT...

• Essayez

OpenDJ:

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

Friday, December 10, 2010

on free...
Concevoir un serveur
ultra-performant en Java :
l'expérience du projet OpenDS

• Ludovic

Poitou

• ludovic.poitou@ForgeRo...
Prochain SlideShare
Chargement dans…5
×

OpenDS - Ludovic Poitou - December 2010

480 vues

Publié le

Performances des serveurs en Java: l'expérience du projet OpenDS - Ludovic Poitou - December 2010

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
480
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
4
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

OpenDS - Ludovic Poitou - December 2010

  1. 1. CONCEVOIR UN SERVEUR ULTRA-PERFORMANT EN JAVA : L'EXPÉRIENCE DU PROJET OPENDS Ludovic Poitou Friday, December 10, 2010 1
  2. 2. 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
  3. 3. • 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. • 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. SEARCHRATE SUR X4170 Friday, December 10, 2010 16
  17. 17. MODRATE SUR X4170 Friday, December 10, 2010 17
  18. 18. REFLEXIONS SUR LA CONCEPTION Photo par Jean-Pierre Dalbera http://www.flickr.com/people/dalbera/ Friday, December 10, 2010 18
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. PATTERNS • Producteurs / Consommateurs • Queues • Pool de Threads • Monitors Friday, December 10, 2010 25
  26. 26. 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
  27. 27. 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
  28. 28. 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
  29. 29. 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
  30. 30. 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
  31. 31. GESTION DU TAS (POUR TOUS LES GCS) Young Generation Old Generation Permanent Generation Friday, December 10, 2010 31
  32. 32. YOUNG GENERATION Allocation (new Object()) Eden Friday, December 10, 2010 Survivor Spaces 32
  33. 33. OLD GENERATION Promotion (survivors from the Young Generation) Friday, December 10, 2010 33
  34. 34. PERMANENT GENERATION Permanent Generation Allocation (only directly from the JVM) Friday, December 10, 2010 34
  35. 35. 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
  36. 36. CONSEIL POUR REGLER LA TAILLE DU TAS DE LA JVM LE PLUS GROS POSSIBLE Friday, December 10, 2010 36
  37. 37. 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
  38. 38. 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
  39. 39. 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
  40. 40. REGLER LA “YOUNG GENERATION” Friday, December 10, 2010 40
  41. 41. 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
  42. 42. 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
  43. 43. 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
  44. 44. 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
  45. 45. 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
  46. 46. GARBAGE FIRST Friday, December 10, 2010 46
  47. 47. 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
  48. 48. 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
  49. 49. 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
  50. 50. 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
  51. 51. 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
  52. 52. 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
  53. 53. 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
  54. 54. 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
  55. 55. 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
  56. 56. 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
  57. 57. 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
  58. 58. 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
  59. 59. 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
  60. 60. MAINTENANT... • Essayez OpenDJ: • http://www.opendj.org • IRC: #opendj • Participez Friday, December 10, 2010 on freenode.net ! 60
  61. 61. 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

×