Diagnostic performances
-
Upload
claude-falguiere -
Category
Technology
-
view
3.853 -
download
7
description
Transcript of Diagnostic performances
Diagnostic performance
Claude Falguière
JUG Toulouse le 7 décembre 2011
JUG Bordeaux le 8 décembre 2011
1
Copyright notice
2
Vous êtes libre de :Reproduire, distribuer et communiquer cette création au publicModifier 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.
http://creativecommons.org/licenses/by/3.0/
Claude Falguière
@cfalguiere
3
Architecte Technique
Co-fondatrice
Crew member
4
5
Faux ami 1La dream Team
X est performantY est performant Z est performant
=> Mon système est performant
Sprint ou marathon ?
6
Vitesse ou charge ?
Modèle Simlocker
Bus RATP
7
Modèle Fiat 500
8
Faux ami 2
C’est du bon sens !
9
User expe!ence
Subjectif Complexité supposéeOrdre d'affichageStabilité
10
Contre-intuitif
Nombreux composantsInteractions complexes
Caches
Mécanismes correctifs
11
Logique
mais souvent
12
Faux ami 3
Avec le cloud fini les problèmes
Essentiellement du scale outDʼautres problèmes liés à la mutualisation (latence I/O)Coût de la montée en charge
13
Jusque là
tout va bien
14
15
Une application ne rend le
service prévu aux utilisateurs que si elle est
déployée
OPS
DEV
16
17
Si vous avez un
marteau
tout ressemble à un
clou18
Donʼt shoot in the dark
19
travailler ensemble ?
20
travailler ensemble ?
21
22
23
http://parisdevops.fr/http://devops.fr
Des User GroupsLilleParisLyonQui sera le prochain ?
24
Partager
25
?Klon!
Zzzzzzzzzz
26
Dis, je comprend pas pourquoi ça
marche pas
Tu peux revéri!er toute la procédure
d’installation ?
Non
A la pêche aux infos
27
Explicitez vos hypothèses
et votre démarche
28
Crime
LaScène
de
29
30
31
32
33
Investigations
34
Que fait ce système ?
Fréquent
VitalRisqué
35
Comment ça marche ?
36
37
38
39
40
41
Ce que vous mesurez soit servir à- bâtir des hypothèses
- (in)valider des hypothèses
42
Patterns
43
FouleGroupeIsolé
Conflits Saturation
Comportement sous stress
44
Ressources limitées + Charge
Saturation
Attente
Capacité
Rejet
45
Accès partagé à la même ressource
Problème de cohabitation
Attente Mélange
Concurrence
46
EfficacitéRépétition
Volume
Attente d’éléments externes
47
48
Utilisateurs actifs CPU
MémoireBande passante réseau
49
Utilisateurs actifs CPU
MémoireBande passante réseau
11 mois plus tard ...
Memory bound : ressource non partageable→ erreur quand plus de ressources
Les limites physiques
50
CPU bound : ressource en time sharing→ partage excessif, lenteur
Network bound : ressource en time sharing→ idem + retry et écroulement
Les Limites configurables
Configuration mémoire de la JVM (-Xmx)Tailles limites de poolTailles limites de cachesNombre dʼinstances, de connexions ...
51
Dimensionner
les pools52
53
Taille du pool
Les tailles de pool
54
Taille du poolMémoire
Les tailles de pool
CPU
Réseau
55
File d’attente
Taille du pool
Les tailles de pool
56
théorie des files d’attente files d’attentes markoviennes (M/M/S)
Y’a Ka
loi de Little
■ λ = fréquence moyenne d'arrivées (loi de Poisson)■ temps moyen de service■ trafic offert (nombre moyen d'arrivées pendant le temps moyen de service)■ S nombre de serveurs
Temps moyen de séjour dans le système (τ)Nombre moyen de clients dans le système (<N>) Probabilité d'attente (Pa)
sources Wikipedia
57
réseau de files d’attentes
58
Approche pragmatique
Estimation globale à partir de tests standardisés (SPEC http://www.spec.org/)
Calibrage par des tests en charge
59
60
attend
( )( )( )
Augmentation des tailles de pools tant que le nombre de runnable n’excède pas le nombre de CPU
(vmstat)
Waiting for I/O
Runnable (mais de
pas de CPU dispo)
61
attend
( )( )( )
Influence de la vitesse des utilisateurs
Influence des jeux
de données
Influence des scénarios joués
62
Tout ce qui rentre doit ressortir ... en moyenne
90
File d’attente = temporisation des pics
63
Cohérence plutôt que
Rock StarS
64
L’entonnoir
Dimensionner
la mémoire65
66
GC, GC
Règle usuelle : temps de GC < 5% uptime process
Memory profiler ou-verbose:gc + GCViewer
67
Les tailles Mémoire
-Xmx800m
4Go
68
Les tailles Mémoire
4Go
OutOfMemory : Not enough swap space left
1,2 Go
-Xmx800m
quota 1Go
69
ne pas prendre tous les messages au pied de la lettre
douter
ulimit, hyperviseurs, shaping réseau, les licences ...
Les Quotas
70
Mutualisation de ressources, Réserver des ressources au système, Priorisation de service,Facturation
71
72
73
1 CPU
74
( )( )
( )
( )( )
( )( )
( )
( )( )
( )( )
( )
( )( )
Tout le monde attend
La limite logicielle est préférable à l’écroulement
Taille du pool trop ambitieuse
75
76
Taille du pool
inefficace
77
78
Ressources limitées +
Ressources non rendues+
Charge
Saturation
MémoireConnexion non rendue au pool Thread bloqué
79
Evaluer l'utilité des caches : thrashing, jamais relus
Utiliser un vrai cache : gestion de la durée de rétention, recyclage,utilisation de weak/soft reference
80
Les pseudos fuites
Récap
Capacité81
Les indicateurs se dégradent progressivement
82
Se produit avec le temps même à faible charge
Se produit sous charge
Souvent écroulement après un pic de charge
Pas de saturation de limites matérielles
Signes
Affecte l’ensemble des use cases
83
Prévention
Tests de vieillissement
Tests en charge
Capacity Planning
84
85
Ressource à partager
Verrou
Lock Transactionnel
(DB)
synchronized(Java)
86
Très long si
attente mutuelle(Deadlock / Livelock)
ou
famine sur le premier
87
Situations propices
variables de classes
variables d’application (compteurs applicatifs)
collections auto-synchronized (Vector, Hashtable)
Java→ Thread Dump + outil d'analyse
(MAT, JCA, HealthCenter, Samourai)
Evaluer les portées des synchronized
BD→ voir les outils de DBA
88
89
90
91
92
Ressource à partager
Verrou
Corruption de données partagées Comportement
instable
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
95
Proposer des alternatives propres
Concurrent Collections
librairie «parallèles» type Gpars
Immutabilité
Thread Local, Volatile
Synchronized à portée réduite
Récap
Concurrence96
Affecte plus certains use case
97
A faible charge
Signes
- Incohérence- Instabilité
- Très faible consommation de ressources- Temps très longs (time-outs)
98
Prévention
Provoquer le conflit par un tests à 2 utilisateurs simultanés
1 des 2 est en erreur ... si vous avez de la chance
Très difficile à identifier
1 des 2 est deux fois plus long
99
Localisé sur un use case
100
Long même en unitaire
Signes
Variations pour un même use case Volume
Préciser le scénario - donnée en cause- volumes / répétition- scénario alternatif
Dresser
le bilan
101
102
Temps de rendering
Temps de réponse serveur
103
104
105
106
107
108
Plusieurs sources
Latences
109
Faire
Les Parler
Chiffres
Série Chronologique
Et sa distribution
110
Quelques mauvais temps isolés
Temps très variables
Bimodale !? ...
111
Que dis cette bimodale ?
112
Comportement différent selon les instances
Plusieurs cas sous le même use case mesuré
Lock
Cache
Que dis cette bimodale ?
113
114
115
- 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
Appels externes
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
117
Complexité algorithmique http://fr.wikipedia.org/wiki/Th%C3%A9orie_de_la_complexit%C3%A9_des_algorithmes
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)
119
VolumeFractionnement
Facteurs de blocage- Ecritures fichiers bufferisées- JDBC Fetch size
Redimensionnement de structures de données non mutables
Conclusion .
120
121
Priorités
Fonctions Robustesse
StabilitéRapidité
122
123
Anticiper ≠ planifier
124
http://javaperformancetuning.com/
http://highscalability.com/
http://velocityconf.com/velocity20xx
Quelques ressources
125
Questions ?
@cfalguiere
Merci pour votre attention
126