Diagnostic performances

Diagnostic performances
Diagnostic performance Claude Falguière JUG Toulouse le 7 décembre 2011 JUG Bordeaux le 8 décembre 2011 1
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
Claude Falguière Architecte Technique Co-fondatrice @cfalguiere Crew member 3
4
Faux ami 1 La dream Team X est performant Y est performant Z est performant => Mon système est performant 5
Sprint ou marathon ? 6
Vitesse ou Bus RATP charge ? Modèle Simlocker Modèle Fiat 500 7
Faux ami 2 C’est du bon sens ! 8
User expe!ence 9
Subjectif Complexité supposée Ordre d'affichage Stabilité 10
Logique mais souvent Nombreux composants Interactions complexes Contre-intuitif Caches Mécanismes correctifs 11
Faux ami 3 Avec le cloud fini les problèmes 12
Essentiellement du scale out Dʼ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
Une application ne rend le service prévu aux utilisateurs que si elle est déployée 15
DEV OPS 16
17
Si vous avez un marteau tout ressemble à un clou 18
Donʼt shoot in the dark 19
travailler ensemble ? 20
21
22
http://parisdevops.fr/ http://devops.fr Des User Groups Lille Paris Lyon Qui sera le prochain ? 23
Partager 24
? n ! Klo Zzzz zzzzz z 25
A la pêche aux infos Dis, je comprend pas pourquoi ça marche pas Tu peux revéri er toute la procédure d’installation ? Non 26
Explicitez vos hypothèses et votre démarche 27
La Scène de Crime 28
29
30
31
32
Investigations 33
Vital Risqué Que fait ce système ? Fréquent 34
Comment ça marche ? 35
36
37
38
39
40
Ce que vous mesurez soit servir à - bâtir des hypothèses - (in)valider des hypothèses 41
Patterns 42
Comportement sous stress Isolé Groupe Foule Conflits Saturation 43
Capacité Ressources limitées + Charge Saturation Attente Rejet 44
Concurrence Accès partagé à la même ressource Problème de cohabitation Attente Mélange 45
Répétition Efficacité Volume Attente d’éléments externes 46
47
Utilisateurs actifs CPU Bande passante réseau Mémoire 48
11 mois plus tard ... Utilisateurs actifs CPU Bande passante réseau Mémoire 49
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 50
Les Limites configurables Configuration mémoire de la JVM (-Xmx) Tailles limites de pool Tailles limites de caches Nombre dʼinstances, de connexions ... 51
Dimensionner les pools 52
Les tailles de pool Taille du pool 53
Les tailles de pool Mémoire Taille du pool CPU Réseau 54
Les tailles de pool File d’attente Taille du pool 55
Y’a Ka sources Wikipedia théorie des files d’attente files d’attentes markoviennes (M/M/S) 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 Nombre moyen de clients dans le système (<N>) Probabilité d'attente (Pa) Temps moyen de séjour dans le système (τ) 56
réseau de files d’attentes 57
Approche pragmatique Estimation globale à partir de tests standardisés (SPEC http://www.spec.org/) Calibrage par des tests en charge 58
59
Waiting for I/O Augmentation des tailles de pools tant que le nombre de ( ) runnable n’excède pas ( ) attend le nombre de CPU ( ) Runnable (vmstat) (mais de pas de CPU dispo) 60
Influence Influence de ( ) des jeux la vitesse des ( ) attend de utilisateurs ( ) données Influence des scénarios joués 61
Tout ce qui rentre doit ressortir ... en moyenne File d’attente = temporisation des pics 90 62
Cohérence plutôt que Rock StarS 63
L’entonnoir 64
Dimensionner la mémoire 65
GC, GC Règle usuelle : temps de GC < 5% uptime process Memory profiler ou -verbose:gc + GCViewer 66
Les tailles Mémoire 4Go -Xmx800m 67
Les tailles Mémoire OutOfMemory : Not enough swap space left 4Go quota 1Go -Xmx800m 1,2 Go 68
douter ne pas prendre tous les messages au pied de la lettre 69
Les Quotas Mutualisation de ressources, Réserver des ressources au système, Priorisation de service, Facturation ulimit, hyperviseurs, shaping réseau, les licences ... 70
71
72
1 CPU 73
La limite logicielle est préférable à l’écroulement ( )( )( ) ( )( )( ) ( )( )( ) ( )( )( ) ( )( )( ) Taille du Tout le pool trop monde attend ambitieuse 74
75
Taille du pool inefficace 76
77
Ressources limitées + Ressources non rendues + Charge Saturation 78
Mémoire Connexion non rendue au pool Thread bloqué 79
Les pseudos fuites 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
Récap Capacité 81
Signes Les indicateurs se dégradent progressivement Se produit sous charge Souvent écroulement Affecte après un pic de charge l’ensemble Pas de saturation de des use cases limites matérielles Se produit avec le temps même à faible charge 82
Prévention Capacity Planning Tests en charge Tests de vieillissement 83
84
Ressource à partager Verrou Lock synchronized Transactionnel (Java) (DB) 85
Très long si attente mutuelle (Deadlock / Livelock) ou famine sur le premier 86
Situations propices variables de classes variables d’application (compteurs applicatifs) collections auto-synchronized (Vector, Hashtable) 87
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
Ressource à partager Verrou Corruption de données partagées Comportement instable 92
Utilisation par plusieurs threads de variables de classe non multi-thread safe (formatters) 93
Situations propices - Optimisations sauvage des synchronized pour régler des problèmes de performance - Caches et compteurs applicatifs mal gérés - Formatters 94
Proposer des alternatives propres Concurrent Collections librairie «parallèles» type Gpars Immutabilité Thread Local, Volatile Synchronized à portée réduite 95
Récap Concurrence 96
Signes - Très faible consommation de ressources - Temps très longs A faible (time-outs) charge Affecte plus certains use case - Incohérence - Instabilité 97
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
Signes Préciser le scénario Long même en unitaire - donnée en cause - volumes / répétition Localisé sur un use case - scénario alternatif Variations pour un même use case Volume 100
Dresser le bilan 101
Temps de Temps de rendering réponse serveur 102
103
104
105
106
107
Plusieurs sources Latences 108
Parler Faire Les Chiffres 109
Série Chronologique Et sa distribution 110
Quelques mauvais temps isolés Temps très variables Bimodale !? ... 111
Que dis cette bimodale ? 112
Que dis cette bimodale ? Comportement différent selon les Plusieurs cas sous instances le même use case mesuré Lock Cache 113
114
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
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
Complexité algorithmique http://fr.wikipedia.org/wiki/Th%C3%A9orie_de_la_complexit%C3%A9_des_algorithmes 117
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
Volume Fractionnement Facteurs de blocage - Ecritures fichiers bufferisées - JDBC Fetch size Redimensionnement de structures de données non mutables 119
Conclusion . 120
Priorités Fonctions Robustesse Stabilité Rapidité 121
122
Anticiper ≠ planifier 123
Quelques ressources http://javaperformancetuning.com/ http://highscalability.com/ http://velocityconf.com/velocity20xx 124
Merci pour votre attention Questions ? @cfalguiere 125
126

Check these out next

Diagnostic performances

Recommended

More Related Content

Similar to Diagnostic performances(20)

More from Claude Falguiere(20)

Recently uploaded(20)

Diagnostic performances