Discussion :

[hemeury]

Bonjour à tous,

Menant une analyse de perf sur une appli qui calcule des itiniéraires, j'ai pris manuellement 9 snapshots à différent moments,
et voici la synthèse des Top 5 Timed Foreground Events:


La grosse majorité du temps est passé en lecture et écriture des donnés.

Une analyse des requetes SQL donnent les résultats suivants:

on rencontre donc des requetes qui prennent 12 MINUTES pour s'éxecuter !!!

Cela vous inspire quoi ?

On sait que le modèle de donnée est catastrophique car les attributs de l'élément de base est sauvegardé dans 4 tables différentes en fonctions des types d'attribut.
Depuis que le volume des données est passé à 60000 élements, les perf se sont vraiment dégradées.

[Pomalaix]

Un rapport statspack présente une vue multifacette de l'activité de la base, et en général une rubrique a besoin de l'éclairage de plusieurs autres pour être interprétée correctement.
En particulier, la rubrique "top 5 events" ne se suffit pas à elle-même.


Par exemple, les attentes "control file sequential read" représentent 70% du temps de traitement en avant plan pour le rapport numéro 2, ce qui est louche a priori.
Mais on ne sait pas quelle est la période couverte par ce rapport, ni quelle était la charge DB time.
Ainsi, si la période couverte est de 1 heure, que le DB time est de 23 secondes, dont 70% de "control file sequential read", circulez, y a rien à voir !
C'est comme si l'événement majeur de ma journée complète était de dire "j'ai mangé une pomme à 11h10".


Concernant vos requêtes, avez-vous pris en compte le fait qu'il faut diviser "Total elapsed time" par le nombre d'exécutions ?


Je vous suggère plutôt de choisir un rapport statspack couvrant une période problématique, et de nous le fournir dans son intégralité.

[hemeury]

Bonjour Pomalaix,

Merci pour ta réponse, et voici les infos demandées.

Test de perfo sur une appli qui génère des trajets style GPS.

Voici la séquence des snaps:
180911_report_7_8_for_developpez_com.pdf180911_report_7_8_for_developpez_com.pdf180911_report_7_8_for_developpez_com.pdf
1 après lancement de l'appli
2 après connexion en tant que "Préparateur"
3 après le chargement de toutes les trajets calculés
4 après la recherche des trajets validés
5 après la recherche d'un trajet précis
6 après la création d'un trajet
7 lors du calcul de trajet
8 lors du calcul de trajet
9 après le calcul de trjet

effectivement la charge du CPU n#est pas significative entre la tache 1 et 2, étant la seule utilisatrice pendant ces tests. Nous avons demandé de réaliser des tests de performances sur la base de prod, afin de bénéficier d'un traffic réel, mais ce n'est pas encore autorisé. Donc on se contente de prendre en main Statspack, et montrer qu'il faut vraiement passer par cette étape de test en conditions réelles.

Voici le rapport d'instance généré entre les snap 7 et 8
180911_report_7_8_for_developpez_com.pdf

[dell68]

Bonjour ,

ça serai plus claire avec un Rapport AWR !

[Ikebukuro]

Je pense que sa boite n'a pas payé le Diagnostic Pack...

[Pomalaix]

Juste quelques mots après un bref coup d'oeil à ce rapport statspack.

Le rapport couvre une période d'environ 15 minutes, c'est un bon dosage permettant des conclusions significatives.
L'activité est faible (équivalent d'une seule session active en moyenne), la consommation CPU très inférieure aux capacités.

La durée des traitements est essentiellement due aux lectures sur disque, dans le cadre d'accès indexés.
(db file sequential read qui représentent 70% du temps total)

Tout se concentre sur la requête suivante, qui représente près de 74% du temps de traitement total, et 99% des lectures physiques
SELECT * FROM VN$VI_A_TROUT_TELEM WHERE EOID_TJNCT_FROM = :B1
700 secondes pour 168 192 exécutions

Les performances d'E/S sont médiocres : environ 20 ms en moyenne. Mais s'il s'agit d'une simple machine de test...

Dans la rubrique "Segments by logical reads" : ce sont les objets SYS.CDEF$ et SYS.TAB$ qui sont prépondérants, et concentrent 70% des lectures logiques à eux deux !
Ceci est tout à fait anormal.
Cependant, les lectures logiques, qui se traduisent par de l'activité CPU, ne constituent pas une part majeure dans l'activité totale.