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