Lecture des rapports de STATPACK 2 Verrous mémoire et Cie

Présentation au sujet: "Lecture des rapports de STATPACK 2 Verrous mémoire et Cie"— Transcription de la présentation:

1 Lecture des rapports de STATPACK 2 Verrous mémoire et Cie
Cours PERFSTAT Lecture des rapports de STATPACK 2 Verrous mémoire et Cie Page 1

2 Sommaire Analyse des verrous mémoire
Analyse lectures logiques et physiques Analyse du cache dictionnaire Activité du cache librairie Page 2

3 Analyse des Verrous (Latch)
Qu ’est-ce qu ’un verrou mémoire ? : Elles permettent de protéger un cache mémoire PARTAGE en verrouillant cette zone dès qu ’un process y accède. Elle est libérée lorsqu ’elle n’est plus utilisée. Une file d ’attente est gérée pour chaque buffer. Les processes en attente sont appellées les ‘ WILLING-TO-WAIT ’, ils réitereront leur demande plus tard. A contrario de les processes appelées ‘ IMMEDIATE ’ ne réitereront pas leur demande s’ils n ’ont pas de verrou immédiatement. Ce temps d ’attente est couteux en temps CPU car si un verrou n ’est pas attribué alors le CPU en refait la demande. Certaines demandes peuvent ne pas être renouvellées, dans ce cas l ’exécution de celle se fera en zone NON partagée. Page 3

4 Pour plus de détails dans les mesures, il faut aller voir dans la table V$LATCH
L ’audit des verrous dans le rapports STATPACK se basent sur les WILLING-TO-WAIT et concerne: Les attentes d ’un process pour obtenir un ‘ VERROU ’ Elle sont mesurées en nombre de demandes de verrous satisfaites et en non satisfaites (abandonnées). Si un grand nombre de process obtiennenent rapidement un ‘ verrou ’ cela signifie 2 choses : Ou que les verrous sont rapidements libérés. Ou qu’il y a peu d ’accès concurrents à un buffer. Page 4

5 Intérêt des verrous Inconvénients
Garantit l ’intégrité des données dans un contexte de partage de données. Garantit un accès aux données demandées à plus ou moins longue échéance Inconvénients Gestion lourde et consommatrice en temps CPU, gestion de files d ’attente supplémentaires. Augmentation des temps d ’attente Difficiles à ‘ tuner ’ Page 5

6 L ’audit se porte sur les valeurs suivantes
Get Requests : Nombre totale de demandes de verrous satisfaites. Pct get misses : Taux de demande non satisfaites de verrous et qui n ’ont pas été réitérées. Avg Slps/Misses : Taux de demandes en attentes qui n ’ont pas été réitérés. Wait time (s) : Temps moyen d ’attente d ’un process avant obtention d ’un verrou. No Wait requests : Nombre de demande satisfaites immédiatement. Pct NoWait misses : Taux de demandes non satisfaites immédiatement et NON réitérées. Page 6

7 Les plus 3 buffers les plus importants de la SHARED POOL
latch Cache buffer chain Cache buffer lru chain Cache buffer (Partie données partagées) LRU Chain Hash chain Library cache Row cache buffer Library cache Dictionnary cache Page 7 Jules Mak-Po-Pan

8 Les plus importants verrous auditées :
Cache buffer chains : Ce verrou protège l ’accès au hash chain du buffer cache. Si le temps t ’attente est élevé c ’est que les recherches dans le cache sont longues. Pct Avg Wait Pct Get Get Slps Time NoWait NoWait Latch Requests Miss /Miss (s) Requests Miss cache buffers chains ,066, , Il a y eu 12,066,792 demandes satisfaites pour un taux de demandes non-satisfaites est de 0,2%, le temps d ’attente moyen avant d ’être satisfait est de 2s. Il y a donc eu beaucoup d ’attentes. En revanche il n ’y a eu que demandes satisfaites immédiatement pour 0% d ’échecs. On en conclu qu’ il y eu beaucoup d ’accès aux buffer cache :  Une entrée du hash-code pointe sur beaucoup de blocs de données : délai de recherche longues.  Une entrée du hash-code pointe sur trop peu de blocs de données : peu de donnés partagées ou groupement de données trop forte. Consulter la vue x$bh pour analyser les hash chains Page 8

9 - Cache buffer LRU chain : Ce verrou est mis lorsqu ’un process cherche à accèder à la liste des objets les plus récemments utilisées (Last Recently Used) dans le cache buffer, ce paramètre permet aux processes d ’accèder directement au buffer SANS recherches: Pct Avg Wait Pct Get Get Slps Time NoWait NoWait Latch Requests Miss /Miss (s) Requests Miss cache buffers lru chain , Il n ’y a eu que 574 demandes satisfaites par le LRU, le taux de demandes non-satisfaites est de 0,0%, le temps d’attente moyen avant d ’être satisfait est de 0s. Le LRU est donc très efficace et peu sollicitée => trop petite. Ceci est symptomatique que : Les données dans la SHARED POOL ont été réutilisées peut de fois dans un cycle LRU. Augmenter le nombre de verrous : Paramètre db_block_lru_latches trop petite Réduire le nombre d ’accès au buffer cache : une shared pool mal taillée. Page 9

10 - Rows Cache objects : Verrou du dictionnaire de données
- Rows Cache objects : Verrou du dictionnaire de données. Ce verrou est très utilisée pendant le parsing. Pct Avg Wait Pct Get Get Slps Time NoWait NoWait Latch Requests Miss /Miss (s) Requests Miss row cache objects ,049, , Il y eu 4,049,353 demandes satisfaites pour un taux de demandes non-satisfaites est de 3,5%, le temps d ’attente moyen avant d ’être satisfait est de 1s. Il y a donc eu beaucoup d ’attentes et 3,5% d ’entre-eux n ’ont pas réitérés leurs demande. Par contre il y a eu PEU de demandes satisfaites directement (1044). Ceci est symptomatique d ’ une mauvaise réutilisation du code, en effet en 25mn il y a eu près de 5000 demandes de parsing Page 10

11 - ROWS Cache enqueue latch : C’est un verrou qui est mis sur la file d ’attente du cache de données partagées. Elle traduit les locks qu ’il y a eu sur le cache dictionnaire. Pct Avg Wait Pct Get Get Slps Time NoWait NoWait Latch Requests Miss /Miss (s) Requests Miss row cache enqueue latch ,049, Il y a eu 4,049,353 demandes satisfaites pour un taux de demandes non-satisfaites est de 0,7%. Il y a donc eu beaucoup de monde dans la file d ’attente du buffer de données partagées. De fait il y a eu beaucoup de résultats partagées avec des process antérieurs et peu (0,7) de renouvellements. Page 11

12 Activité des verrous Pct Avg Wait Pct
Get Get Slps Time NoWait NoWait Latch Requests Miss /Miss (s) Requests Miss row cache enqueue latch ,049, row cache objects ,049, , shared pool , Le % de demandes non réitérées (Pct Misses) les plus importantes concernent le ROW Cache Objects, la Row cache enqueue latch et la share pool. Cela signifie que : - 3,5% des demandes d ’accès au ROW Cache Objects ont fini par être faites ‘ailleurs’ et que l ’attente pour obtenir un verrous sur ce cache a été en moyenne de 1s - En 25mn il y a eu peu de transfer de données en shared pool. Ou la shared pool se suffit à elle-même ou les même transactions ont été passées plusieurs fois, ou elle est trop petite. Page 12

13 Conclusion de l ’analyse des verrous :
Beaucoup demandes de verrous Files d ’attente trop longue Recherches longues dans la Shared Pool SHARED POOL AREA trop grande donc temps de recherche longue Mécanisme LRU peu sollicitée : faible taux de réutilisation des données récentes. Beaucoup de changements de données dans le cache Peu de demandes de transfert dans la Shared Pool Peu de données dans le DATA BUFFER CACHE sont éligibles pour le partage. SHARED POOL AREA trop petite car peu de transfers inter-caches. Page 13

14 SHARED POOL AREA TROP GRANDE :
Confirmée par la SHARED POOL ADIVISORY Estd Shared Pool SP Estd Estd Estd Lib LC Time Size for Size Lib Cache Lib Cache Cache Time Saved Estd Lib Cache Estim (M) Factr Size (M) Mem Obj Saved (s) Factr Mem Obj Hits , , ,964,280 , , ,964,280 , , ,964,280 , , ,964,280 , , ,964,280 , , ,964,280 , , ,964,280 , , ,964,280 Page 14

15 Sommaire Analyse des verrous mémoire
Analyse lectures logiques et physiques Analyse du cache dictionnaire Activité du cache librairie Page 15

16 Top 5 : Lectures en cache par segments
Subobject Obj Logical Owner Tablespace Object Name Name Type Reads %Total ADELIE SILODECL_I IX_DONNEE_TVA_ PT_2003T4 INDEX , ADELIE SILODECL_I IX_DONNEE_TVA_ PT_2004T1 INDEX , ADELIE SILODECL_I IX_DONNEE_TVA_ PT_2002T2 INDEX , ADELIE SILODECL_I IX_DONNEE_TVA_ PT_2002T4 INDEX , ADELIE SILODECL_I IX_DONNEE_TVA_ PT_2003T2 INDEX , Environ 25% des lectures en cache se sont fait sur un seul index : DONNEE_TVA. Intérêt du partitionnement 25% sur le même tablespace Page 16

17 Lectures physiques par segments
Owner Tablespace Object Name Name Type Reads %Total ADELIE SILODECL_I IX_DONNEE_TVA_ PT_2003T4 INDEX , ADELIE SILODECL_D DEPOT_TVA PT_2003T4 TABLE , ADELIE SILODECL_D DONNEE_TVA PT_2003T4 TABLE , ADELIE SILODECL_D DONNEE_TVA PT_2004T1 TABLE , ADELIE SILODECL_I IX_IMPRIME_TVA_03 PT_2003T4 INDEX , 11,5% des lectures physiques sur DONNEE_TVA 6,7% de lecture physiques sur l ’index IX_DONNE_TVA (P4) !!! Alors qu ’une partie est déjà dans le cache. 12,8% des lectures physiques sur la partition des données PT_2003T4 12,5% des lectures physiques sur partition d ’index PT_2003T4 Page 17

18 Top 5 : Attentes dans le cache par segments
Owner Tablespace Object Name Name Type Reads %Total ADELIE SILODECL_I IX_DONNEE_TVA_ PT_2003T4 INDEX , ADELIE SILODECL_D DEPOT_TVA PT_2003T4 TABLE , ADELIE SILODECL_D DONNEE_TVA PT_2003T4 TABLE , ADELIE SILODECL_D DONNEE_TVA PT_2004T1 TABLE , ADELIE SILODECL_I IX_IMPRIME_TVA_03 PT_2003T4 INDEX , 11,5% concernent DONNEE_TVA = Lectures physiques Dont 6,7% sur un de ses indexes Page 18

19 Conclusions Attentes dues aux lectures physiques
12,8% des lectures physiques concernent la même partition d ’un tablespace Indexes pas totalement chargées en cache entraine des lectures physiques. Etude du poids des I/Os nécessaire pour rééquilibrage des partitions de DONNEE_TVA Utiliser le paramètre BUFFER_POOL_KEEP pour garder un max de temps une table en mémoire (Attention mécanisme LRU) Précéder les requêtes par un ALTER TABLE DONNEE_TVA CACHE. Page 19

20 Sommaire Analyse des verrous mémoire
Analyse lectures logiques et physiques Analyse du cache dictionnaire Activité du cache librairie Page 20

21 Analyse du cache dictionnaire
Contient les objets système Contient les objets des schémas Ce sont les objets les plus sollicités Page 21

22 Statistiques du le cache dictionnaire
Get Pct Scan Pct Mod Final Cache Requests Miss Reqs Miss Reqs Usage dc_free_extents dc_histogram_defs , dc_object_ids , dc_objects , dc_profiles dc_rollback_segments dc_segments , dc_sequences dc_tablespaces , dc_user_grants dc_usernames dc_users , Forte sollicitation en ‘select ’ (DC_ROLLBACK_SEGMENTS). Beaucoup d ’utilisateurs connectés (DC_USERS) Base peu sollicitée en mise à jour (dc_rollback_segments) Page 22

23 Conclusion Base utilisée en select Beaucoup de connexions à gérer :
Gestion des accès Gestion des droits Gestion des définitions d ’objets Page 23

24 Sommaire Analyse des verrous mémoire
Analyse lectures logiques et physiques Analyse du cache dictionnaire Activité du cache librairie Page 24

25 Activité du cache librairie
Library Cache Activity for DB: SILODECL Instance: SILODECL Snaps: 5 -9 ->"Pct Misses" should be very low Get Pct Pin Pct Invali- Namespace Requests Miss Requests Miss Reloads dations BODY INDEX , , SQL AREA , , TABLE/PROCEDURE , , TRIGGER Beaucoup de pertes dans la SQL aréa : 1558 demandes d ’accès : 39,9% de demandes non résolues 5929 demandes de chargement de code dans la SQL aréa mais 21% non faits. Page 25

26 Conclusion 39,9% des recherches de codes SQL n ’ont pas aboutit
21% de chargement de code qui n ’ont pu être faits Page 26