jules mak-po-pan page 1 cours perfstat lecture des rapports de statpack 2 verrous mémoire et cie

Jules Mak-Po-Pan

Cours PERFSTAT

Lecture des rapports de STATPACK 2

Verrous mémoire et Cie

Jules Mak-Po-Pan

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

Jules Mak-Po-Pan

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.

Jules Mak-Po-Pan

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

Jules Mak-Po-Pan

+ Intérêt des verrous– 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 ’

Jules Mak-Po-Pan

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

Jules Mak-Po-Pan

• Les plus 3 buffers les plus importants de la SHARED POOL

Hash chain

Cache buffer (Partie données partagées) LRU Chain

Dictionnary cacheLibrary cache

Cache buffer chain Cache buffer lru chain

Row cache buffer

Library cache

Sha-redpoollatch

Jules Mak-Po-Pan

• 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 12,066,792 0.2 0.0 2 27,445 0.0

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

Jules Mak-Po-Pan

- 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


------------------------ -------------- ------ ------ ------ ------------ ------

cache buffers lru chain 574 0.0 0 27,299 0.2

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.

Jules Mak-Po-Pan

- Rows Cache objects : Verrou du dictionnaire de données. Ce verrou est très utilisée pendant le parsing.

Pct Avg Wait Pct



------------------------ -------------- ------ ------ ------ ------------ ------

row cache objects 4,049,353 3.5 0.0 1 1,044 0.0

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

Jules Mak-Po-Pan

- 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



------------------------ -------------- ------ ------ ------ ------------ ------

row cache enqueue latch 4,049,016 0.7 0.0 0 0

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.

Jules Mak-Po-Pan

• Activité des verrous Pct Avg Wait Pct



------------------------ -------------- ------ ------ ------ ------------ ------

row cache enqueue latch 4,049,016 0.7 0.0 0 0

row cache objects 4,049,353 3.5 0.0 1 1,044 0.0

shared pool 96,091 0.8 0.1 0 0

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.

Jules Mak-Po-Pan

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

Jules Mak-Po-Pan

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

----------- ----- ---------- ------------ ------------ ------- ---------------

48 .6 89 4,027 12,593 1.0 1,964,280

64 .8 104 6,601 12,593 1.0 1,964,280

80 1.0 110 7,219 12,593 1.0 1,964,280

96 1.2 110 7,219 12,593 1.0 1,964,280

112 1.4 110 7,219 12,593 1.0 1,964,280

128 1.6 110 7,219 12,593 1.0 1,964,280

144 1.8 110 7,219 12,593 1.0 1,964,280

160 2.0 110 7,219 12,593 1.0 1,964,280

Jules Mak-Po-Pan


Jules Mak-Po-Pan

• Top 5 : Lectures en cache par segments Subobject Obj. Logical

Owner Tablespace Object Name Name Type Reads %Total

---------- ---------- -------------------- ---------- ----- ------------ -------

ADELIE SILODECL_I IX_DONNEE_TVA_03 PT_2003T4 INDEX 383,120 5.44





– 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

Jules Mak-Po-Pan

• Lectures physiques par segmentsOwner Tablespace Object Name Name Type Reads %Total

---------- ---------- -------------------- ---------- ----- ------------ -------


ADELIE SILODECL_D DEPOT_TVA PT_2003T4 TABLE 1,451 6.45

ADELIE SILODECL_D DONNEE_TVA PT_2003T4 TABLE 1,411 6.27


ADELIE SILODECL_I IX_IMPRIME_TVA_03 PT_2003T4 INDEX 1,197 5.32

-------------------------------------------------------------

– 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

Jules Mak-Po-Pan

• Top 5 : Attentes dans le cache par segments

Owner Tablespace Object Name Name Type Reads %Total

---------- ---------- -------------------- ---------- ----- ------------ -------


ADELIE SILODECL_D DEPOT_TVA PT_2003T4 TABLE 1,451 6.45



ADELIE SILODECL_I IX_IMPRIME_TVA_03 PT_2003T4 INDEX 1,197 5.32

-------------------------------------------------------------

– 11,5% concernent DONNEE_TVA = Lectures physiques

– Dont 6,7% sur un de ses indexes

Jules Mak-Po-Pan

• 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_TVAUtiliser 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.

Jules Mak-Po-Pan


Jules Mak-Po-Pan

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

Jules Mak-Po-Pan

• Statistiques du le cache dictionnaire Get Pct Scan Pct Mod Final

Cache Requests Miss Reqs Miss Reqs Usage

------------------------- ------------ ------ ------- ----- -------- ----------

dc_free_extents 4 0.0 0 0 1

dc_histogram_defs 52,550 0.0 0 0 294

dc_object_ids 58,825 0.0 0 0 270

dc_objects 5,412 0.0 0 0 613

dc_profiles 40 0.0 0 0 1

dc_rollback_segments 56 0.0 0 0 12

dc_segments 5,206 0.0 0 0 282

dc_sequences 2 0.0 0 2 3

dc_tablespaces 939,944 0.0 0 0 49

dc_user_grants 244 0.0 0 0 17

dc_usernames 80 0.0 0 0 8

dc_users 962,453 0.0 0 0 23

-------------------------------------------------------------

– Forte sollicitation en ‘select ’ (DC_ROLLBACK_SEGMENTS).– Beaucoup d ’utilisateurs connectés (DC_USERS)– Base peu sollicitée en mise à jour (dc_rollback_segments)

Jules Mak-Po-Pan

• Conclusion– Base utilisée en select– Beaucoup de connexions à gérer :

• Gestion des accès• Gestion des droits• Gestion des définitions d ’objets

Jules Mak-Po-Pan


Jules Mak-Po-Pan

• Activité du cache librairieLibrary 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 28 0.0 28 0.0 0 0

INDEX 19,204 0.0 6,370 0.0 0 0

SQL AREA 1,558 39.9 5,929 21.3 16 0

TABLE/PROCEDURE 12,287 0.0 16,131 0.0 3 0

TRIGGER 68 0.0 68 0.0 0 0

-------------------------------------------------------------

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.

Jules Mak-Po-Pan

• Conclusion– 39,9% des recherches de codes SQL n ’ont

pas aboutit– 21% de chargement de code qui n ’ont pu

être faits

jules mak-po-pan page 1 cours perfstat lecture des rapports de statpack 2 verrous mémoire et cie

Documents