Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Charge de la base de données
La charge de la base de données (charge DB) mesure le niveau d'activité de la session de votre base de données. La métrique clé de Performance Insights est DBLoad, qui est collectée toutes les secondes.
Sessions actives
Une session de base de données représente le dialogue d'une application avec une base de données relationnelle. Une session active est une connexion qui a transmis du travail au moteur de base de données et qui attend une réponse.
Une session est active lorsqu'elle s'exécute sur le processeur (CPU) ou attend qu'une ressource devienne disponible pour pouvoir continuer. Par exemple, une session active peut attendre qu'une page (ou un bloc) soit lue en mémoire avant d'utiliser le processeur pendant la lecture des données de la page.
Sessions actives en moyenne
Les sessions actives en moyenne (AAS) représentent l'unité de la métrique DBLoad de Performance Insights. Elle mesure le nombre de sessions actives simultanément sur la base de données.
Toutes les secondes, Performance Insights échantillonne le nombre de sessions exécutant simultanément une requête. Pour chaque session active, Performance Insights collecte les données suivantes :
-
Instruction SQL
-
État de la session (en cours d'exécution sur le processeur ou en attente)
-
Host (Hôte)
-
Utilisateur exécutant le SQL
Performance Insights calcule les AAS en divisant le nombre total de sessions par le nombre d'échantillons pour une période déterminée. Par exemple, la table suivante présente 5 échantillons consécutifs d'une requête en cours d'exécution, prélevés à des intervalles d'une seconde.
| Exemple | Nombre de sessions exécutant la requête | AAS | Calcul |
|---|---|---|---|
| 1 | 2 | 2 | 2 sessions au total/1 échantillon |
| 2 | 0 | 1 | 2 sessions au total/2 échantillons |
| 3 | 4 | 2 | 6 sessions au total/3 échantillons |
| 4 | 0 | 1.5 | 6 sessions au total/4 échantillons |
| 5 | 4 | 2 | 10 sessions au total/5 échantillons |
Dans l'exemple précédent, la charge de la base de données pour l'intervalle de temps était de 2 AAS. Cette mesure signifie qu'en moyenne, deux sessions étaient actives à la fois à n'importe quel moment au cours de la période où les cinq échantillons ont été prélevés.
L'activité des employés au sein d'un entrepôt représente une bonne analogie avec la charge de base de données. Supposons qu'un entrepôt emploie 100 employés. Lorsqu'une commande est réceptionnée, elle traitée par un employé et les 99 autres sont inactifs. Si 100 commandes sont réceptionnées, les 100 employés traitent les commandes simultanément. Si, toutes les 15 minutes, un responsable note le nombre d'employés actifs simultanément, additionne ces chiffres à la fin de la journée, puis divise le total par le nombre d'échantillons, il calcule le nombre moyen d'employés actifs à un moment donné. Si la moyenne était de 50 employés hier et qu'elle est aujourd'hui de 75 employés, cela indique que le niveau d'activité moyen dans l'entrepôt a augmenté. De la même manière, la charge de la base de données augmente à mesure que l'activité de la session de la base de données augmente.
Exécutions actives moyennes
La moyenne des exécutions actives (AAE) par seconde est liée à l'AAS. Pour calculer l'AAE, Performance Insights divise la durée totale d'exécution d'une requête par l'intervalle de temps. Le tableau suivant présente le calcul de l'AAE pour la même requête que dans le tableau précédent.
| Temps écoulé (en secondes) | Durée totale d'exécution (en secondes) | AAE | Calcul |
|---|---|---|---|
| 60 | 120 | 2 | 120 secondes d'exécution/60 secondes écoulées |
| 120 | 120 | 1 | 120 secondes d'exécution/120 secondes écoulées |
| 180 | 380 | 2.11 | 380 secondes d'exécution/180 secondes écoulées |
| 240 | 380 | 1.58 | 380 secondes d'exécution/240 secondes écoulées |
| 300 | 600 | 2 | 600 secondes d'exécution/300 secondes écoulées |
Dans la plupart des cas, l'AAS et l'AAE d'une requête sont approximativement identiques. Cela dit, comme les données utilisées pour les calculs proviennent de sources différentes, les calculs varient souvent légèrement.
Dimensions
La métrique db.load est différente des autres métriques de série chronologique, car vous pouvez la décomposer en sous-composants appelés dimensions. Vous pouvez considérer les dimensions comme des catégories de « tranches » pour les différentes caractéristiques de la métrique DBLoad.
Lorsque vous diagnostiquez des problèmes de performances, les dimensions suivantes sont souvent les plus utiles :
Pour obtenir la liste complète des dimensions des moteurs Amazon RDS, veuillez consulter Charge de base de données tranchée par dimensions.
Événements d'attente
Un événement d'attente fait qu'une instruction SQL attend qu'un événement spécifique se produise avant de pouvoir continuer à s'exécuter. Les événements d'attente constituent une dimension (ou catégorie) importante pour la charge de la base de données, car ils indiquent les points de blocage du travail.
Chaque session active est soit en cours d'exécution au niveau du processeur soit en attente. Par exemple, les sessions sollicitent le processeur lorsqu'elles recherchent un tampon dans la mémoire, effectuent un calcul ou exécutent du code procédural. Lorsque les sessions ne sollicitent pas le processeur, c'est peut-être qu'elles attendent qu'un tampon de mémoire se libère, qu'un fichier de données soit lu ou qu'un journal soit écrit. Le temps que passe une session à attendre des ressources est autant de temps en moins qu'elle passe à s'exécuter au niveau du processeur.
Lorsque vous réglez une base de données, vous cherchez souvent à identifier les ressources que les sessions attendent. Par exemple, deux ou trois événements d'attente peuvent représenter 90 % de la charge de la base de données. Cette mesure signifie qu'en moyenne, les sessions actives passent la majeure partie de leur temps à attendre un petit nombre de ressources. Si vous trouvez la cause de ces attentes, vous pouvez tenter une solution.
Considérez l'analogie avec un magasinier. Une commande de livre est réceptionnée. L'employé peut être retardé dans le traitement de la commande. Par exemple, un employé est peut-être en train de réapprovisionner les étagères, aucun chariot n'est disponible, ou le système servant à saisir l'état des commandes se montre très lent. Plus le salarié attend, plus le traitement de la commande prend du temps. Bien que l'attente fasse partie intégrante du flux de l'entrepôt, si le temps d'attente devient excessif, la productivité s'en ressent. De la même manière, les attentes longues ou répétées d'une session peuvent dégrader les performances de la base de données. Pour plus d'informations, consultez Réglage des événements d'attente pour Aurora PostgreSQL et Réglage des événements d'attente pour Aurora MySQL dans le Guide de l'utilisateur Amazon Aurora.
Les événements d'attente varient en fonction du moteur de base de données :
-
Pour plus d'informations sur tous les événements d'attente MariaDB et MySQL, veuillez consulter Wait Event Summary Tables
dans la documentation MySQL. -
Pour plus d'informations sur tous les événements d'attente PostgreSQL, consultez The Statistics Collector > Wait Event tables
dans la documentation de PostgreSQL. -
Pour plus d'informations sur tous les événements d'attente Oracle, veuillez consulter Descriptions of Wait Events
dans la documentation Oracle. -
Pour plus d'informations sur tous les événements d'attente SQL Server, veuillez consulter Types of Waits
dans la documentation SQL Server.
Note
Pour Oracle, les processus en arrière-plan s'exécutent parfois sans instruction SQL associée. Dans ce cas, Performance Insights communique le type de processus en arrière-plan concaténé avec le signe deux-points, et la classe d'attente associée à ce processus en arrière-plan. Parmi les types de processus en arrière-plan figurent LGWR, ARC0, PMON, etc.
Par exemple, lorsque le programme d'archivage effectue des opérations d'I/O, le rapport Performance Insights correspondant est similaire à ARC1:System I/O. Parfois, le type du processus en arrière-plan est également omis et Performance Insights communique uniquement la classe d'attente, par exemple :System
I/O.
Principaux éléments SQL
Là où les événements d'attente présentent des goulots d'étranglement, les principaux éléments SQL indiquent quelles requêtes contribuent le plus à la charge de la base de données. Par exemple, de nombreuses requêtes peuvent être en cours d'exécution sur la base de données, mais une seule d'entre elles peut consommer 99 % de la charge de la base de données. Dans ce cas, la charge élevée peut indiquer un problème avec la requête.
Par défaut, la console Performance Insights affiche les principales requêtes SQL qui contribuent à la charge de la base de données. La console affiche également des statistiques pertinentes pour chaque instruction. Pour diagnostiquer les problèmes de performances d'une instruction spécifique, vous pouvez examiner son plan d'exécution.
Plans
Un plan d'exécution, également appelé simplement un plan, est une séquence d'étapes qui accèdent aux données. Par exemple, un plan de jonction de tables t1 et t2 peut parcourir toutes les lignes de t1 et comparer chaque ligne à une ligne de t2. Dans une base de données relationnelle, un optimiseur est un code intégré qui détermine le plan le plus efficace pour une requête SQL.
Pour les instances de base de données Oracle, Performance Insights collecte automatiquement les plans d'exécution. Pour diagnostiquer les problèmes de performances SQL, examinez les plans capturés pour les requêtes Oracle SQL à ressources élevées. Les plans montrent comment Oracle Database a analysé et exécuté des requêtes.
Pour savoir comment analyser la charge de base de données à l'aide de plans, veuillez consulter Analyse des plans d'exécution d'Oracle à l'aide du tableau de bord de Performance Insights.
Capture du plan
Toutes les cinq minutes, Performance Insights identifie les requêtes Oracle les plus gourmandes en ressources et capture leurs plans. Ainsi, vous n'avez pas besoin de collecter et de gérer manuellement un grand nombre de plans. Au lieu de cela, vous pouvez utiliser l'onglet Top SQL (Principaux éléments SQL) pour vous concentrer sur les plans des requêtes les plus problématiques.
Note
Performance Insights ne capture pas de plans pour les requêtes dont le texte dépasse la limite maximale de texte de requête collectable. Pour de plus amples informations, veuillez consulter Accès à plus de texte SQL dans le tableau de bord Performance Insights.
La période de conservation des plans d'exécution est la même que pour vos données Performance Insights. Le paramètre de rétention dans l'offre gratuite est Par défaut (7 jours). Pour conserver vos données de performance plus longtemps, indiquez 1 à 24 mois. Pour obtenir plus d'informations sur les périodes de conservation, consultez Tarification et conservation des données pour Performance Insights.
Requêtes récapitulatives
L'onglet Top SQL (Principaux éléments SQL) affiche les requêtes récapitulatives par défaut. Une requête récapitulative n'a pas elle-même de plan, mais toutes les requêtes utilisant des valeurs littérales ont des plans. Par exemple, une requête récapitulative peut inclure le texte WHERE `email`=?. Le récapitulatif peut contenir deux requêtes, l'une avec le texte WHERE email=user1@example.com et l'autre avec WHERE
email=user2@example.com. Chacune de ces requêtes littérales peut inclure plusieurs plans.
Si vous sélectionnez une requête de récapitulative, la console affiche tous les plans pour les instructions enfant du récapitulatif sélectionné. Par conséquent, vous n'avez pas besoin de parcourir toutes les instructions enfant pour trouver le plan. Vous pouvez voir des plans qui ne figurent pas dans la liste affichée des 10 premières instructions enfant. La console affiche les plans pour toutes les requêtes enfant pour lesquelles des plans ont été collectés, que les requêtes figurent ou non dans les 10 premières requêtes.
