Your SlideShare is downloading. ×

Diagnostic performances

3,933

Published on

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

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
3,933
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
30
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Diagnostic performance Claude Falguière JUG Toulouse le 7 décembre 2011 JUG Bordeaux le 8 décembre 2011 1
  • 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. Claude FalguièreArchitecte Technique Co-fondatrice @cfalguiere Crew member 3
  • 4. 4
  • 5. Faux ami 1 La dream Team X est performant Y est performant Z est performant =>Mon système est performant 5
  • 6. Sprint ou marathon ?6
  • 7. Vitesse ou Bus RATPcharge ? Modèle Simlocker Modèle Fiat 500 7
  • 8. Faux ami 2C’est du bon sens ! 8
  • 9. User expe!ence 9
  • 10. Subjectif Complexité supposée Ordre daffichage Stabilité 10
  • 11. Logiquemais souvent Nombreux composants Interactions complexesContre-intuitif Caches Mécanismes correctifs 11
  • 12. Faux ami 3Avec le cloud fini les problèmes 12
  • 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. Jusque làtoutva bien 14
  • 15. Une application ne rend le service prévuaux utilisateurs que si elle est déployée 15
  • 16. DEV OPS 16
  • 17. 17
  • 18. Si vous avez unmarteautout ressemble à unclou 18
  • 19. Donʼt shoot in the dark 19
  • 20. travailler ensemble  ? 20
  • 21. 21
  • 22. 22
  • 23. http://parisdevops.fr/http://devops.frDes User Groups Lille Paris Lyon Qui sera le prochain ? 23
  • 24. Partager 24
  • 25. ? n ! KloZzzz zzzzz z 25
  • 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. Explicitez vos hypothèseset votre démarche 27
  • 28. LaScène de Crime 28
  • 29. 29
  • 30. 30
  • 31. 31
  • 32. 32
  • 33. Investigations 33
  • 34. Vital RisquéQue fait ce système ? Fréquent 34
  • 35. Comment ça marche ? 35
  • 36. 36
  • 37. 37
  • 38. 38
  • 39. 39
  • 40. 40
  • 41. Ce que vous mesurez soit servir à - bâtir des hypothèses - (in)valider des hypothèses 41
  • 42. Patterns 42
  • 43. Comportement sous stress Isolé Groupe Foule Conflits Saturation 43
  • 44. Capacité Ressources limitées + Charge Saturation Attente Rejet 44
  • 45. ConcurrenceAccès partagé à la même ressource Problème de cohabitation Attente Mélange 45
  • 46. Répétition Efficacité VolumeAttente d’éléments externes 46
  • 47. 47
  • 48. Utilisateurs actifs CPUBande passante réseau Mémoire 48
  • 49. 11 mois plus tard ...Utilisateurs actifs CPUBande passante réseau Mémoire 49
  • 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. 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. Dimensionner les pools 52
  • 53. Les tailles de pool Taille du pool 53
  • 54. Les tailles de pool Mémoire Taille du pool CPURéseau 54
  • 55. Les tailles de pool File d’attente Taille du pool 55
  • 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. réseau de files d’attentes 57
  • 58. Approche pragmatique Estimation globale à partir de tests standardisés (SPEC http://www.spec.org/) Calibrage par des tests en charge 58
  • 59. 59
  • 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. Influence Influence de ( ) des jeuxla vitesse des ( ) attend de utilisateurs ( ) données Influence des scénarios joués 61
  • 62. Tout ce qui rentre doitressortir ... en moyenne File d’attente = temporisation des pics 90 62
  • 63. Cohérence plutôt queRock StarS 63
  • 64. L’entonnoir 64
  • 65. Dimensionner la mémoire 65
  • 66. GC, GC Règle usuelle : temps de GC < 5% uptime process Memory profiler ou -verbose:gc + GCViewer 66
  • 67. Les tailles Mémoire 4Go -Xmx800m 67
  • 68. Les tailles Mémoire OutOfMemory : Not enough swap space left 4Go quota 1Go -Xmx800m 1,2 Go 68
  • 69. douter ne pas prendre tous lesmessages au pied de la lettre 69
  • 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
  • 72. 72
  • 73. 1 CPU 73
  • 74. La limite logicielle est préférable à l’écroulement( )( )( )( )( )( )( )( )( )( )( )( )( )( )( ) Taille du Tout le pool trop monde attend ambitieuse 74
  • 75. 75
  • 76. Taille du pool inefficace76
  • 77. 77
  • 78. Ressources limitées +Ressources non rendues + Charge Saturation 78
  • 79. MémoireConnexion non rendue au poolThread bloqué 79
  • 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. RécapCapacité 81
  • 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. Prévention Capacity Planning Tests en charge Tests de vieillissement 83
  • 84. 84
  • 85. Ressource à partager Verrou Lock synchronizedTransactionnel (Java) (DB) 85
  • 86. Très long si attente mutuelle (Deadlock / Livelock) ou famine sur le premier86
  • 87. Situations propicesvariables de classesvariables d’application (compteurs applicatifs)collections auto-synchronized (Vector, Hashtable) 87
  • 88. Java→ Thread Dump + outil danalyse (MAT, JCA, HealthCenter, Samourai)Evaluer les portées des synchronizedBD→ voir les outils de DBA 88
  • 89. 89
  • 90. 90
  • 91. 91
  • 92. Ressource à partager VerrouCorruption de données partagées Comportement instable 92
  • 93. Utilisation par plusieurs threads de variables de classe non multi-thread safe (formatters)93
  • 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. Proposer des alternatives propresConcurrent Collectionslibrairie «parallèles» type GparsImmutabilitéThread Local, VolatileSynchronized à portée réduite 95
  • 96. RécapConcurrence 96
  • 97. Signes - Très faible consommation de ressources - Temps très longsA faible (time-outs)chargeAffecte pluscertains use case - Incohérence - Instabilité 97
  • 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
  • 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. Dresserle bilan 101
  • 102. Temps de Temps derendering réponse serveur 102
  • 103. 103
  • 104. 104
  • 105. 105
  • 106. 106
  • 107. 107
  • 108. Plusieurs sources Latences 108
  • 109. ParlerFaireLesChiffres 109
  • 110. Série ChronologiqueEt sa distribution 110
  • 111. Quelques mauvais temps isolésTemps très variables Bimodale !? ... 111
  • 112. Que dis cette bimodale ? 112
  • 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
  • 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. 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. Complexité algorithmique http://fr.wikipedia.org/wiki/Th%C3%A9orie_de_la_complexit%C3%A9_des_algorithmes 117
  • 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. VolumeFractionnement Facteurs de blocage - Ecritures fichiers bufferisées - JDBC Fetch size Redimensionnement de structures de données non mutables 119
  • 120. Conclusion . 120
  • 121. Priorités Fonctions Robustesse Stabilité Rapidité 121
  • 122. 122
  • 123. Anticiper ≠ planifier 123
  • 124. Quelques ressources http://javaperformancetuning.com/ http://highscalability.com/ http://velocityconf.com/velocity20xx 124
  • 125. Merci pour votre attention Questions ? @cfalguiere 125
  • 126. 126

×