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
1. Diagnostic performance
Claude Falguière
Geneva JUG
le 12 Octobre 2011
1
jeudi 13 octobre 2011
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 l'auteur original de la manière indiquée par
l'auteur de l'oeuvre ou le titulaire des droits qui vous confère cette autorisation (mais
pas d'une manière qui suggérerait qu'ils vous soutiennent ou approuvent votre
utilisation de l'oeuvre).
Rien dans ce contrat ne diminue ou ne restreint le droit moral de l'auteur ou des
auteurs.
2
jeudi 13 octobre 2011
23. Combien ? Quand ?
Quelle heure ?
Quel jour ?
Pics
23
jeudi 13 octobre 2011
24. Pourquoi ?
Les enjeux Les coûts
24
jeudi 13 octobre 2011
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?
25
jeudi 13 octobre 2011
26. Pourquoi ?
Temps de réponse
et
Disponibilité, Stabilité GALERIEopWEG
Robustesse
Vieillissement
Résistance à l'effet Twitter
Consommation de ressources
26
jeudi 13 octobre 2011 G
27. Garbage in
Garbage out
27
jeudi 13 octobre 2011
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
28
jeudi 13 octobre 2011
29. Trouvez des biais Trouvez des biais qui
qui rendront le rendront le résultat
résultat meilleur plus mauvais
29
jeudi 13 octobre 2011
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
83
jeudi 13 octobre 2011
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
84
jeudi 13 octobre 2011
85. Les Quotas
ulimit, hyperviseurs, shaping réseau, les licences ...
Mutualisation de ressources,
Réserver des ressources au système,
Priorisation de service,
Facturation
85
jeudi 13 octobre 2011
86. Les Limites configurables
Configuration mémoire de la JVM (-Xmx)
Tailles limites de pool
Tailles limites de caches
Nombre dʼinstances, de connexions ...
86
jeudi 13 octobre 2011
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)
89
jeudi 13 octobre 2011
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
91
jeudi 13 octobre 2011
92. dimensionnement
La limite logicielle est préférable à
l’écroulement
92
jeudi 13 octobre 2011
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
93
jeudi 13 octobre 2011
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
100
jeudi 13 octobre 2011
101. Cohérence
plutôt que
Rock StarS
101
jeudi 13 octobre 2011
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
105
jeudi 13 octobre 2011
106. Mémoire
Connexion non rendue au pool
Thread bloqué
106
jeudi 13 octobre 2011
107. Les pseudo fuites
... aka les caches
Evaluer l'utilité :
thrashing, jamais relus
Utiliser un vrai cache :
durée de rétention,
recyclage
Weak reference,
soft reference
107
jeudi 13 octobre 2011
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
111
jeudi 13 octobre 2011
112. Java
→ Thread Dump + outil d'analyse
(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
112
jeudi 13 octobre 2011
115. Utilisation par plusieurs
threads de variables de
classe non multi-thread safe
(formatters)
115
jeudi 13 octobre 2011
116. - Erreurs d'incohé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
116
jeudi 13 octobre 2011
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
117
jeudi 13 octobre 2011
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
120
jeudi 13 octobre 2011
122. Que dis cette bimodale ?
Comportement
différent selon les Plusieurs cas sous
instances le même use case
mesuré
Lock
Cache
122
jeudi 13 octobre 2011
123. Patience et
longueur de
temps ...
123
jeudi 13 octobre 2011
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
125
jeudi 13 octobre 2011
126. Lorsque vous avez éliminé
l'impossible, ce qui reste, si
improbable soit-il, est nécessairement
la vérité.
Arthur Conan Doyle
(Le signe des quatre)
126
jeudi 13 octobre 2011
128. Non contributifs
Les erreurs dans les logs
(en permanence)
Uniquement sur la nouvelle plate-forme Non applicatif
Peu d'utilisateurs et de requêtes Exclus la charge
Aucun signe de saturation avant le crash
Perte du monitoring
Réseau ?
L'OS est inaccessible
Tout marche après redémarrage de l'OS 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
128
jeudi 13 octobre 2011
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
L'OS est inaccessible
Uniquement sur la nouvelle plate-forme Applicatif
L'ancienne plate-forme avait été modifiée
129
jeudi 13 octobre 2011