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 base de données
Le chargement de la base de données (DB load) mesure le niveau d'activité de session dans votre base de données. DBLoadest la métrique clé de Database Insights, et Database Insights collecte la charge de la base de données 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
La moyenne des sessions actives (AAS) est l'unité de la DBLoad métrique dans Database Insights. Elle mesure le nombre de sessions actives simultanément sur la base de données.
Chaque seconde, Database Insights échantillonne le nombre de sessions exécutant simultanément une requête. Pour chaque session active, Database 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
Database Insights calcule l'AAS en divisant le nombre total de sessions par le nombre d'échantillons pour une période donné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.
Exécutions actives moyennes
La moyenne des exécutions actives (AAE) par seconde est liée à l’AAS. Pour calculer l'AAE, Database Insights divise le temps d'exécution total 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 seconds/60 écoulées |
| 120 | 120 | 1 | 120 secondes d'exécution seconds/120 écoulées |
| 180 | 380 | 2.11 | 380 secondes d'exécution seconds/180 écoulées |
| 240 | 380 | 1.58 | 380 secondes d'exécution seconds/240 écoulées |
| 300 | 600 | 2 | 600 secondes d'exécution seconds/300 é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 Aurora, consultez Database Insights.
É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.
Les événements d’attente varient en fonction du moteur de base de données :
-
Pour obtenir la liste des événements d’attente courants pour Aurora MySQL, consultez Événements d’attente Aurora MySQL. Pour savoir comment régler l’utilisation de ces événements d’attente, consultez Réglage d'Aurora MySQL.
-
Pour plus d’informations sur tous les événements d’attente MySQL, consultez Wait Event Summary Tables
dans la documentation MySQL. -
Pour obtenir la liste des événements d’attente courants pour Aurora PostgreSQL, consultez Événements d’attente Amazon Aurora PostgreSQL. Pour savoir comment régler l’utilisation de ces événements d’attente, consultez Réglage des événements d’attente pour Aurora PostgreSQL.
-
Pour plus d’informations sur tous les événements d’attente PostgreSQL, consultez The Statistics Collector > Wait Event tables
dans la documentation de PostgreSQL.
Top SQL (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 Database 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.
