Diagnostic performances

5,500 views

Published on

Présentation aux JUGs de Toulouse et Bordeaux en décembre 2011

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
5,500
On SlideShare
0
From Embeds
0
Number of Embeds
3,211
Actions
Shares
0
Downloads
45
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Diagnostic performances

  1. 1. Diagnostic performance Claude Falguière JUG Toulouse le 7 décembre 2011 JUG Bordeaux le 8 décembre 2011 1
  2. 2. Copyright notice http://creativecommons.org/licenses/by/3.0/Vous êtes libre de :Reproduire, distribuer et communiquer cette création au publicModifier cette créationSelon les conditions suivantes :Paternité. Vous devez citer le nom de lauteur original de la manière indiquée parlauteur de loeuvre ou le titulaire des droits qui vous confère cette autorisation (maispas dune manière qui suggérerait quils vous soutiennent ou approuvent votreutilisation de loeuvre).Rien dans ce contrat ne diminue ou ne restreint le droit moral de lauteur ou desauteurs. 2
  3. 3. Claude FalguièreArchitecte Technique Co-fondatrice @cfalguiere Crew member 3
  4. 4. 4
  5. 5. Faux ami 1 La dream Team X est performant Y est performant Z est performant =>Mon système est performant 5
  6. 6. Sprint ou marathon ?6
  7. 7. Vitesse ou Bus RATPcharge ? Modèle Simlocker Modèle Fiat 500 7
  8. 8. Faux ami 2C’est du bon sens ! 8
  9. 9. User expe!ence 9
  10. 10. Subjectif Complexité supposée Ordre daffichage Stabilité 10
  11. 11. Logiquemais souvent Nombreux composants Interactions complexesContre-intuitif Caches Mécanismes correctifs 11
  12. 12. Faux ami 3Avec le cloud fini les problèmes 12
  13. 13. Essentiellement du scale outDʼautres problèmes liés à la mutualisation (latence I/O)Coût de la montée en charge 13
  14. 14. Jusque làtoutva bien 14
  15. 15. Une application ne rend le service prévuaux utilisateurs que si elle est déployée 15
  16. 16. DEV OPS 16
  17. 17. 17
  18. 18. Si vous avez unmarteautout ressemble à unclou 18
  19. 19. Donʼt shoot in the dark 19
  20. 20. travailler ensemble  ? 20
  21. 21. 21
  22. 22. 22
  23. 23. http://parisdevops.fr/http://devops.frDes User Groups Lille Paris Lyon Qui sera le prochain ? 23
  24. 24. Partager 24
  25. 25. ? n ! KloZzzz zzzzz z 25
  26. 26. A la pêche aux infosDis, je comprendpas pourquoi ça marche pas Tu peux revéri er toute la procédure d’installation ? Non 26
  27. 27. Explicitez vos hypothèseset votre démarche 27
  28. 28. LaScène de Crime 28
  29. 29. 29
  30. 30. 30
  31. 31. 31
  32. 32. 32
  33. 33. Investigations 33
  34. 34. Vital RisquéQue fait ce système ? Fréquent 34
  35. 35. Comment ça marche ? 35
  36. 36. 36
  37. 37. 37
  38. 38. 38
  39. 39. 39
  40. 40. 40
  41. 41. Ce que vous mesurez soit servir à - bâtir des hypothèses - (in)valider des hypothèses 41
  42. 42. Patterns 42
  43. 43. Comportement sous stress Isolé Groupe Foule Conflits Saturation 43
  44. 44. Capacité Ressources limitées + Charge Saturation Attente Rejet 44
  45. 45. ConcurrenceAccès partagé à la même ressource Problème de cohabitation Attente Mélange 45
  46. 46. Répétition Efficacité VolumeAttente d’éléments externes 46
  47. 47. 47
  48. 48. Utilisateurs actifs CPUBande passante réseau Mémoire 48
  49. 49. 11 mois plus tard ...Utilisateurs actifs CPUBande passante réseau Mémoire 49
  50. 50. Les limites physiquesMemory bound :ressource non partageable→ erreur quand plus de ressourcesCPU bound :ressource en time sharing→ partage excessif, lenteurNetwork bound :ressource en time sharing→ idem + retry et écroulement 50
  51. 51. Les Limites configurables Configuration mémoire de la JVM (-Xmx) Tailles limites de pool Tailles limites de caches Nombre dʼinstances, de connexions ... 51
  52. 52. Dimensionner les pools 52
  53. 53. Les tailles de pool Taille du pool 53
  54. 54. Les tailles de pool Mémoire Taille du pool CPURéseau 54
  55. 55. Les tailles de pool File d’attente Taille du pool 55
  56. 56. Y’a Ka sources Wikipedia théorie des files d’attente files d’attentes markoviennes (M/M/S) loi de Little ■ λ = fréquence moyenne darrivées (loi de Poisson) ■ temps moyen de service ■ trafic offert (nombre moyen darrivées pendant le temps moyen de service) ■ S nombre de serveurs Nombre moyen de clients dans le système (<N>) Probabilité dattente (Pa) Temps moyen de séjour dans le système (τ) 56
  57. 57. réseau de files d’attentes 57
  58. 58. Approche pragmatique Estimation globale à partir de tests standardisés (SPEC http://www.spec.org/) Calibrage par des tests en charge 58
  59. 59. 59
  60. 60. Waiting for I/OAugmentation destailles de pools tantque le nombre de ( )runnable n’excède pas ( ) attendle nombre de CPU ( ) Runnable(vmstat) (mais de pas de CPU dispo) 60
  61. 61. Influence Influence de ( ) des jeuxla vitesse des ( ) attend de utilisateurs ( ) données Influence des scénarios joués 61
  62. 62. Tout ce qui rentre doitressortir ... en moyenne File d’attente = temporisation des pics 90 62
  63. 63. Cohérence plutôt queRock StarS 63
  64. 64. L’entonnoir 64
  65. 65. Dimensionner la mémoire 65
  66. 66. GC, GC Règle usuelle : temps de GC < 5% uptime process Memory profiler ou -verbose:gc + GCViewer 66
  67. 67. Les tailles Mémoire 4Go -Xmx800m 67
  68. 68. Les tailles Mémoire OutOfMemory : Not enough swap space left 4Go quota 1Go -Xmx800m 1,2 Go 68
  69. 69. douter ne pas prendre tous lesmessages au pied de la lettre 69
  70. 70. Les QuotasMutualisation de ressources,Réserver des ressources au système,Priorisation de service,Facturation ulimit, hyperviseurs, shaping réseau, les licences ... 70
  71. 71. 71
  72. 72. 72
  73. 73. 1 CPU 73
  74. 74. La limite logicielle est préférable à l’écroulement( )( )( )( )( )( )( )( )( )( )( )( )( )( )( ) Taille du Tout le pool trop monde attend ambitieuse 74
  75. 75. 75
  76. 76. Taille du pool inefficace76
  77. 77. 77
  78. 78. Ressources limitées +Ressources non rendues + Charge Saturation 78
  79. 79. MémoireConnexion non rendue au poolThread bloqué 79
  80. 80. Les pseudos fuites Evaluer lutilité des caches : thrashing, jamais relus Utiliser un vrai cache : gestion de la durée de rétention, recyclage, utilisation de weak/soft reference 80
  81. 81. RécapCapacité 81
  82. 82. Signes Les indicateurs se dégradent progressivementSe produitsous charge Souvent écroulementAffecte après un pic de chargel’ensemble Pas de saturation dedes use cases limites matériellesSe produit avec le tempsmême à faible charge 82
  83. 83. Prévention Capacity Planning Tests en charge Tests de vieillissement 83
  84. 84. 84
  85. 85. Ressource à partager Verrou Lock synchronizedTransactionnel (Java) (DB) 85
  86. 86. Très long si attente mutuelle (Deadlock / Livelock) ou famine sur le premier86
  87. 87. Situations propicesvariables de classesvariables d’application (compteurs applicatifs)collections auto-synchronized (Vector, Hashtable) 87
  88. 88. Java→ Thread Dump + outil danalyse (MAT, JCA, HealthCenter, Samourai)Evaluer les portées des synchronizedBD→ voir les outils de DBA 88
  89. 89. 89
  90. 90. 90
  91. 91. 91
  92. 92. Ressource à partager VerrouCorruption de données partagées Comportement instable 92
  93. 93. Utilisation par plusieurs threads de variables de classe non multi-thread safe (formatters)93
  94. 94. Situations propices- Optimisations sauvage des synchronized pour régler des problèmes de performance- Caches et compteurs applicatifs mal gérés- Formatters 94
  95. 95. Proposer des alternatives propresConcurrent Collectionslibrairie «parallèles» type GparsImmutabilitéThread Local, VolatileSynchronized à portée réduite 95
  96. 96. RécapConcurrence 96
  97. 97. Signes - Très faible consommation de ressources - Temps très longsA faible (time-outs)chargeAffecte pluscertains use case - Incohérence - Instabilité 97
  98. 98. Prévention Provoquer le conflit par un tests à 2 utilisateurs simultanés 1 des 2 est deux fois plus long 1 des 2 est en erreur ... si vous avez de la chance Très difficile à identifier 98
  99. 99. 99
  100. 100. Signes Préciser le scénarioLong même en unitaire - donnée en cause - volumes / répétitionLocalisé sur un use case - scénario alternatifVariations pour unmême use case Volume 100
  101. 101. Dresserle bilan 101
  102. 102. Temps de Temps derendering réponse serveur 102
  103. 103. 103
  104. 104. 104
  105. 105. 105
  106. 106. 106
  107. 107. 107
  108. 108. Plusieurs sources Latences 108
  109. 109. ParlerFaireLesChiffres 109
  110. 110. Série ChronologiqueEt sa distribution 110
  111. 111. Quelques mauvais temps isolésTemps très variables Bimodale !? ... 111
  112. 112. Que dis cette bimodale ? 112
  113. 113. Que dis cette bimodale ? Comportement différent selon les Plusieurs cas sous instances le même use case mesuré Lock Cache 113
  114. 114. 114
  115. 115. Appels externes- Limiter le temps d’attente et les traiter les non-réponse en erreur- Logguer les temps anormaux aux extrémités du système- utiliser des appels asynchrones 115
  116. 116. Répétition - log, requêtes JDBC dans des boucles - requêtes involontaires (cascade, refresh) - répétition induite par le volume de données bon candidat pour la parallélisation techniques de Map Reduce - problèmes d’algorithme 116
  117. 117. Complexité algorithmique http://fr.wikipedia.org/wiki/Th%C3%A9orie_de_la_complexit%C3%A9_des_algorithmes 117
  118. 118. Structures de données- Informations additionnelles (index, tri)- Organisation de l’information pour faciliter les parcours- Structures spécialisées (tables de hachage, arbres équilibrés) 118
  119. 119. VolumeFractionnement Facteurs de blocage - Ecritures fichiers bufferisées - JDBC Fetch size Redimensionnement de structures de données non mutables 119
  120. 120. Conclusion . 120
  121. 121. Priorités Fonctions Robustesse Stabilité Rapidité 121
  122. 122. 122
  123. 123. Anticiper ≠ planifier 123
  124. 124. Quelques ressources http://javaperformancetuning.com/ http://highscalability.com/ http://velocityconf.com/velocity20xx 124
  125. 125. Merci pour votre attention Questions ? @cfalguiere 125
  126. 126. 126

×