Diagnostic performances

1,379 views

Published on

Je constate souvent que les gens cherchent la cause des problèmes de performance sans stratégie et sans coopérer entre métiers.
Sur la base de mon expérience, je vais présenter des moyens qui permettent de partager l’information et élaborer un diagnostic de problème deperformance :
- comment procéder pour ne pas chercher au hasard,
- quelles informations sont utiles,
- les patterns de comportement qu’on retrouve souvent et qui nous mettent sur une piste,
- les vérifications à faire via le monitoring ou les logs pour confirmer l’hypothèse

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
1,379
On SlideShare
0
From Embeds
0
Number of Embeds
99
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Diagnostic performances

  1. 1. Diagnostic performance Claude Falguière Geneva JUG le 12 Octobre 2011 1jeudi 13 octobre 2011
  2. 2. Copyright notice http://creativecommons.org/licenses/by/3.0/ Vous êtes libre de : Reproduire, distribuer et communiquer cette création au public Modifier cette création Selon les conditions suivantes : Paternité. Vous devez citer le nom de lauteur original de la manière indiquée par lauteur de loeuvre ou le titulaire des droits qui vous confère cette autorisation (mais pas dune manière qui suggérerait quils vous soutiennent ou approuvent votre utilisation de loeuvre). Rien dans ce contrat ne diminue ou ne restreint le droit moral de lauteur ou des auteurs. 2jeudi 13 octobre 2011
  3. 3. Claude Falguière @cfalguiere Technique 3jeudi 13 octobre 2011
  4. 4. 4jeudi 13 octobre 2011
  5. 5. Faux ami 1 La dream Team X est performant Y est performant Z est performant => Mon système est performant 5jeudi 13 octobre 2011
  6. 6. Sprint ou marathon ? 6jeudi 13 octobre 2011
  7. 7. Bus RATP Vitesse ou charge ? Modèle Fiat 500 Modèle Simlocker 7jeudi 13 octobre 2011
  8. 8. Faux ami 2 C’est du bon sens ! 8jeudi 13 octobre 2011
  9. 9. User expe!ence 9jeudi 13 octobre 2011
  10. 10. Subjectif Complexité supposée Ordre daffichage Stabilité 10jeudi 13 octobre 2011
  11. 11. Logique mais souvent Nombreux composants Interactions complexes Caches Contre-intuitif Mécanismes correctifs 11jeudi 13 octobre 2011
  12. 12. Faux ami 3 Avec le cloud fini les problèmes 12jeudi 13 octobre 2011
  13. 13. Essentiellement du scale out Dʼautres problèmes liés à la mutualisation (latence I/O) Coût de la montée en charge 13jeudi 13 octobre 2011
  14. 14. S(t)imuler 14jeudi 13 octobre 2011
  15. 15. 15jeudi 13 octobre 2011
  16. 16. Quels vont faire les utilisateurs en production ? 16jeudi 13 octobre 2011
  17. 17. Les volumétries ? Les dimensionnements ? 17jeudi 13 octobre 2011
  18. 18. Les risques à vérifier ? Les critères à mesurer ? 18jeudi 13 octobre 2011
  19. 19. Qui ? Quoi ? Où ? Quand ? Combien ? Comment ? Pourquoi ? 19jeudi 13 octobre 2011
  20. 20. Qui ? 20jeudi 13 octobre 2011
  21. 21. Qui ? Quoi ? Consultations Paie Recherche complexe 21jeudi 13 octobre 2011
  22. 22. Qui ? Quoi ? 22jeudi 13 octobre 2011
  23. 23. Combien ? Quand ? Quelle heure ? Quel jour ? Pics 23jeudi 13 octobre 2011
  24. 24. Pourquoi ? Les enjeux Les coûts 24jeudi 13 octobre 2011
  25. 25. STRATEGIE DE TEST POURQUOI ? Que veut on évaluer ? Quels sont les enjeux ? QUOI ? COMBIEN ? Combien d utilisateurs ? Combien de temps ? Quel pro l de charge ? COMMENT ? Environnement requis ? Jeux de données? 25jeudi 13 octobre 2011
  26. 26. Pourquoi ? Temps de réponse et Disponibilité, Stabilité GALERIEopWEG Robustesse Vieillissement Résistance à leffet Twitter Consommation de ressources 26jeudi 13 octobre 2011 G
  27. 27. Garbage in Garbage out 27jeudi 13 octobre 2011
  28. 28. Garbage In → Garbage Out Biais Martineric Le résultat du test dépend totalement des scénarios définis et de leur implémentation 28jeudi 13 octobre 2011
  29. 29. Trouvez des biais Trouvez des biais qui qui rendront le rendront le résultat résultat meilleur plus mauvais 29jeudi 13 octobre 2011
  30. 30. Volumétries 30jeudi 13 octobre 2011
  31. 31. Structure des données 31jeudi 13 octobre 2011
  32. 32. Gestion des erreurs Bref ... pas facile 32jeudi 13 octobre 2011
  33. 33. Cumulus 33jeudi 13 octobre 2011
  34. 34. DEV OPS 34jeudi 13 octobre 2011
  35. 35. 35jeudi 13 octobre 2011
  36. 36. Si vous avez un marteau tout ressemble à un clou 36jeudi 13 octobre 2011
  37. 37. Donʼt shoot in the dark 37jeudi 13 octobre 2011
  38. 38. travailler ensemble  ? 38jeudi 13 octobre 2011
  39. 39. 39jeudi 13 octobre 2011
  40. 40. 40jeudi 13 octobre 2011
  41. 41. Et chez vous ? 41jeudi 13 octobre 2011
  42. 42. Partager 42jeudi 13 octobre 2011
  43. 43. 43jeudi 13 octobre 2011
  44. 44. Explicitez vos hypothèses et votre démarche 44jeudi 13 octobre 2011
  45. 45. 45jeudi 13 octobre 2011
  46. 46. 46jeudi 13 octobre 2011
  47. 47. 47jeudi 13 octobre 2011
  48. 48. LaScène de Crime 48jeudi 13 octobre 2011
  49. 49. 49jeudi 13 octobre 2011
  50. 50. 50jeudi 13 octobre 2011
  51. 51. 51jeudi 13 octobre 2011
  52. 52. 52jeudi 13 octobre 2011
  53. 53. 53jeudi 13 octobre 2011
  54. 54. Investigations 54jeudi 13 octobre 2011
  55. 55. Que fait ce système ? 55jeudi 13 octobre 2011
  56. 56. 56jeudi 13 octobre 2011
  57. 57. Comment ça marche ? 57jeudi 13 octobre 2011
  58. 58. 58jeudi 13 octobre 2011
  59. 59. 59jeudi 13 octobre 2011
  60. 60. 60jeudi 13 octobre 2011
  61. 61. 61jeudi 13 octobre 2011
  62. 62. 62jeudi 13 octobre 2011
  63. 63. Jusque là tout va bien 63jeudi 13 octobre 2011
  64. 64. 64jeudi 13 octobre 2011
  65. 65. 65jeudi 13 octobre 2011
  66. 66. Dresser le bilan 66jeudi 13 octobre 2011
  67. 67. 67jeudi 13 octobre 2011
  68. 68. 68jeudi 13 octobre 2011
  69. 69. 69jeudi 13 octobre 2011
  70. 70. 70jeudi 13 octobre 2011
  71. 71. 71jeudi 13 octobre 2011
  72. 72. 72jeudi 13 octobre 2011
  73. 73. 73jeudi 13 octobre 2011
  74. 74. Gagnez du temps 74jeudi 13 octobre 2011
  75. 75. Série Chronologique Et sa distribution 75jeudi 13 octobre 2011
  76. 76. Quelques mauvais temps isolés Temps très variables Bimodale !? ... 76jeudi 13 octobre 2011
  77. 77. Douter 77jeudi 13 octobre 2011
  78. 78. Latences 78jeudi 13 octobre 2011
  79. 79. Patterns 79jeudi 13 octobre 2011
  80. 80. 80jeudi 13 octobre 2011
  81. 81. La rançon du succès 81jeudi 13 octobre 2011
  82. 82. 82jeudi 13 octobre 2011
  83. 83. - Se produit sous charge - Affecte tous les use cases Confirmation Accroissement de l’usage sur une longue période Trouver les limites atteintes - time outs - ressources saturées 83jeudi 13 octobre 2011
  84. 84. Les limites physiques Memory bound : ressource non partageable → erreur quand plus de ressources CPU bound : ressource en time sharing → partage excessif, lenteur Network bound : ressource en time sharing → idem + retry et écroulement 84jeudi 13 octobre 2011
  85. 85. Les Quotas ulimit, hyperviseurs, shaping réseau, les licences ... Mutualisation de ressources, Réserver des ressources au système, Priorisation de service, Facturation 85jeudi 13 octobre 2011
  86. 86. Les Limites configurables Configuration mémoire de la JVM (-Xmx) Tailles limites de pool Tailles limites de caches Nombre dʼinstances, de connexions ... 86jeudi 13 octobre 2011
  87. 87. 87jeudi 13 octobre 2011
  88. 88. 88jeudi 13 octobre 2011
  89. 89. - Se produit sous charge - Affecte tous les use cases - Souvent écroulement après un pic de charge Résolution Trouver la bonne configuration - utilisation optimale du CPU et pas plus - vmstat (runnable) 89jeudi 13 octobre 2011
  90. 90. Le régime restrictif 90jeudi 13 octobre 2011
  91. 91. - Se produit sous charge - Affecte tous les use cases Confirmation Saturation de limites configurées mais pas des limites matérielles Résolution Lever ces limites 91jeudi 13 octobre 2011
  92. 92. dimensionnement La limite logicielle est préférable à l’écroulement 92jeudi 13 octobre 2011
  93. 93. Comment dimensionner ? Dimensionnement par tests de charge - respecter le modèle de charge de l’utilisateur Influence de la vitesse des utilisateurs - attentes sur le serveur Web ou le container Web Influence des jeux de données - attentes de la base de données 93jeudi 13 octobre 2011
  94. 94. 94jeudi 13 octobre 2011
  95. 95. 95jeudi 13 octobre 2011
  96. 96. 96jeudi 13 octobre 2011
  97. 97. 97jeudi 13 octobre 2011
  98. 98. 98jeudi 13 octobre 2011
  99. 99. 99jeudi 13 octobre 2011
  100. 100. dimensionnement Tout ce qui rentre doit ressortir … en moyenne Les actifs sont définis par la taille du pool Les files d’attente régulent les variations de débit 100jeudi 13 octobre 2011
  101. 101. Cohérence plutôt que Rock StarS 101jeudi 13 octobre 2011
  102. 102. 102jeudi 13 octobre 2011
  103. 103. L emprunt à durée indéterminée 103jeudi 13 octobre 2011
  104. 104. 104jeudi 13 octobre 2011
  105. 105. - Se produit avec le temps même à faible charge - Affecte tous les use cases - Les indicateurs se dégradent progressivement Résolution Trouver la fuite ... - Tester les use case isolément, la fuite est souvent liée à un scénario particulier - Certains outils d’introspection détectent les fuites de connexion sur les pools 105jeudi 13 octobre 2011
  106. 106. Mémoire Connexion non rendue au pool Thread bloqué 106jeudi 13 octobre 2011
  107. 107. Les pseudo fuites ... aka les caches Evaluer lutilité : thrashing, jamais relus Utiliser un vrai cache : durée de rétention, recyclage Weak reference, soft reference 107jeudi 13 octobre 2011
  108. 108. La voie unique 108jeudi 13 octobre 2011
  109. 109. 109jeudi 13 octobre 2011
  110. 110. 110jeudi 13 octobre 2011
  111. 111. - Très faible consommation de ressources - Temps très longs (time-outs) - Affecte particulièrement certains use cases et à faible charge Confirmation Trouver le lock Provoquer le lock - test à 2 utilisateurs synchronisés → 1 des 2 est deux fois plus long 111jeudi 13 octobre 2011
  112. 112. Java → Thread Dump + outil danalyse (MAT, JCA, HealthCenter, Samourai) Evaluer les portées des synchronized Attention aux variables communes (données et compteurs applicatifs) BD → voir les outils de DBA 112jeudi 13 octobre 2011
  113. 113. La chaise musicale 113jeudi 13 octobre 2011
  114. 114. 114jeudi 13 octobre 2011
  115. 115. Utilisation par plusieurs threads de variables de classe non multi-thread safe (formatters) 115jeudi 13 octobre 2011
  116. 116. - Erreurs dincohérence - Affecte plus certains use cases - A faible charge - Instabilité Confirmation Provoquer le problème - test synchronisés → 1 des 2 est en erreur ... si vous avez de la chance 116jeudi 13 octobre 2011
  117. 117. Très difficile à identifier Causes courantes : - Optimisations sauvage des synchronized pour régler des problèmes de performance - Caches et compteurs applicatifs mal gérés - Formatters Solutions possibles : → Thread Local, synchronized, volatile 117jeudi 13 octobre 2011
  118. 118. 118jeudi 13 octobre 2011
  119. 119. 119jeudi 13 octobre 2011
  120. 120. - localisé sur un use case - variations dans un use case Préciser le scénario - donnée en cause - volumes / répétition - scénario alternatif 120jeudi 13 octobre 2011
  121. 121. Que dis cette bimodale ? 121jeudi 13 octobre 2011
  122. 122. Que dis cette bimodale ? Comportement différent selon les Plusieurs cas sous instances le même use case mesuré Lock Cache 122jeudi 13 octobre 2011
  123. 123. Patience et longueur de temps ... 123jeudi 13 octobre 2011
  124. 124. 124jeudi 13 octobre 2011
  125. 125. Le processus Dresser le bilan → Comprendre où ça se passe à peu près Mesurer ce qui permet - de choisir un pattern - de comprendre la cause Eliminer des hypothèses Ne pas choisir une vérité trop rapidement Boucler 125jeudi 13 octobre 2011
  126. 126. Lorsque vous avez éliminé limpossible, ce qui reste, si improbable soit-il, est nécessairement la vérité. Arthur Conan Doyle (Le signe des quatre) 126jeudi 13 octobre 2011
  127. 127. 127jeudi 13 octobre 2011
  128. 128. Non contributifs Les erreurs dans les logs (en permanence) Uniquement sur la nouvelle plate-forme Non applicatif Peu dutilisateurs et de requêtes Exclus la charge Aucun signe de saturation avant le crash Perte du monitoring Réseau ? LOS est inaccessible Tout marche après redémarrage de lOS Donc pas coupure réseau Perte du service systématique après 2j ouvrés Vieillissement ? mais pas de symptômes ... Et qui peut bloquer l’accès à l’OS 128jeudi 13 octobre 2011
  129. 129. Fuite de connexions LDAP Limite du nombre de connexions réseau autorisées sous Windows Plus d’accès réseau Perte du monitoring LOS est inaccessible Uniquement sur la nouvelle plate-forme Applicatif Lancienne plate-forme avait été modifiée 129jeudi 13 octobre 2011
  130. 130. Conclusion . 130jeudi 13 octobre 2011
  131. 131. Priorités Fonctions Robustesse Stabilité Rapidité 131jeudi 13 octobre 2011
  132. 132. 132jeudi 13 octobre 2011
  133. 133. 133jeudi 13 octobre 2011
  134. 134. 134jeudi 13 octobre 2011
  135. 135. 135jeudi 13 octobre 2011

×