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 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

Claude FalguièreArchitecte Technique Co-fondatrice @cfalguiere Crew member 3

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 RATPcharge ? Modèle Simlocker Modèle Fiat 500 7

Faux ami 2C’est du bon sens ! 8

User expe!ence 9

Subjectif Complexité supposée Ordre dafﬁchage Stabilité 10

Logiquemais souvent Nombreux composants Interactions complexesContre-intuitif Caches Mécanismes correctifs 11

Faux ami 3Avec le cloud ﬁni les problèmes 12

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àtoutva bien 14

Une application ne rend le service prévuaux utilisateurs que si elle est déployée 15

DEV OPS 16

Si vous avez unmarteautout ressemble à unclou 18

Donʼt shoot in the dark 19

travailler ensemble ? 20

http://parisdevops.fr/http://devops.frDes User Groups Lille Paris Lyon Qui sera le prochain ? 23

Partager 24

? n ! KloZzzz zzzzz z 25

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

Explicitez vos hypothèseset votre démarche 27

LaScène de Crime 28

Investigations 33

Vital RisquéQue fait ce système ? Fréquent 34

Comment ça marche ? 35

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 Conﬂits Saturation 43

Capacité Ressources limitées + Charge Saturation Attente Rejet 44

ConcurrenceAccès partagé à la même ressource Problème de cohabitation Attente Mélange 45

Répétition Efﬁcacité VolumeAttente d’éléments externes 46

Utilisateurs actifs CPUBande passante réseau Mémoire 48

11 mois plus tard ...Utilisateurs actifs CPUBande passante réseau Mémoire 49

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

Les Limites configurables Conﬁguration 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 CPURé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 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

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

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

Influence Influence de ( ) des jeuxla vitesse des ( ) attend de utilisateurs ( ) données Influence des scénarios joués 61

Tout ce qui rentre doitressortir ... en moyenne File d’attente = temporisation des pics 90 62

Cohérence plutôt queRock StarS 63

L’entonnoir 64

Dimensionner la mémoire 65

GC, GC Règle usuelle : temps de GC < 5% uptime process Memory proﬁler 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 lesmessages au pied de la lettre 69

Les QuotasMutualisation de ressources,Réserver des ressources au système,Priorisation de service,Facturation ulimit, hyperviseurs, shaping réseau, les licences ... 70

1 CPU 73

La limite logicielle est préférable à l’écroulement( )( )( )( )( )( )( )( )( )( )( )( )( )( )( ) Taille du Tout le pool trop monde attend ambitieuse 74

Taille du pool inefficace76

Ressources limitées +Ressources non rendues + Charge Saturation 78

MémoireConnexion non rendue au poolThread bloqué 79

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

RécapCapacité 81

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

Prévention Capacity Planning Tests en charge Tests de vieillissement 83

Ressource à partager Verrou Lock synchronizedTransactionnel (Java) (DB) 85

Très long si attente mutuelle (Deadlock / Livelock) ou famine sur le premier86

Situations propicesvariables de classesvariables d’application (compteurs applicatifs)collections auto-synchronized (Vector, Hashtable) 87

Java→ Thread Dump + outil danalyse (MAT, JCA, HealthCenter, Samourai)Evaluer les portées des synchronizedBD→ voir les outils de DBA 88

Ressource à partager VerrouCorruption 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 propresConcurrent Collectionslibrairie «parallèles» type GparsImmutabilitéThread Local, VolatileSynchronized à portée réduite 95

RécapConcurrence 96

Signes - Très faible consommation de ressources - Temps très longsA faible (time-outs)chargeAffecte pluscertains 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

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

Dresserle bilan 101

Temps de Temps derendering réponse serveur 102

Plusieurs sources Latences 108

ParlerFaireLesChiffres 109

Série ChronologiqueEt sa distribution 110

Quelques mauvais temps isolésTemps 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

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

VolumeFractionnement Facteurs de blocage - Ecritures ﬁchiers bufferisées - JDBC Fetch size Redimensionnement de structures de données non mutables 119

Conclusion . 120

Priorités Fonctions Robustesse Stabilité Rapidité 121

Anticiper ≠ planiﬁer 123

Quelques ressources http://javaperformancetuning.com/ http://highscalability.com/ http://velocityconf.com/velocity20xx 124

Merci pour votre attention Questions ? @cfalguiere 125

http://toulousejug.org	940
http://cfalguiere.wordpress.com	542
http://www.kanithael.net	151
http://feeds.feedburner.com	14
http://127.0.0.1	2
http://www.codesorceresses.eu	1

Diagnostic performances

by Claude Falguiere on Dec 13, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

6 Embeds 1,650

Statistics

Diagnostic performances — Presentation Transcript