Charge de la base de données - Amazon Aurora

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 base de données (charge de base de données) mesure le niveau d'activité de session dans votre base de données. DBLoadest l'indicateur clé de Performance Insights, et Performance Insights collecte la charge de base de données chaque seconde.

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 est en cours d'exécution CPU ou lorsqu'elle attend qu'une ressource soit disponible pour pouvoir continuer. Par exemple, une session active peut attendre qu'une page (ou un bloc) soit lu en mémoire, puis consommer CPU pendant qu'elle lit les données de la page.

Sessions actives en moyenne

La moyenne des sessions actives (AAS) est l'unité de la DBLoad métrique dans 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 :

  • SQLdéclaration

  • État de la session (en cours d'exécution CPU ou en attente)

  • Host (Hôte)

  • Utilisateur exécutant le SQL

Performance Insights calcule le 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 base de données pour l'intervalle de temps était de 2AAS. 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 àAAS. Pour calculer leAAE, Performance Insights divise le temps d'exécution total d'une requête par l'intervalle de temps. Le tableau suivant indique le AAE calcul pour la même requête dans le tableau précédent.

Temps écoulé (en secondes) Durée totale d'exécution (en secondes) AAE Calculs
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, les AAE termes AAS et pour 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, consultezCharge de base de données tranchée par dimensions.

Événements d'attente

Un événement d'attente oblige une SQL instruction à attendre 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, CPU soit en attente. Par exemple, les sessions consomment CPU lorsqu'elles recherchent une mémoire tampon, effectuent un calcul ou exécutent du code procédural. Lorsque les sessions ne sont pas trop gourmandesCPU, elles peuvent attendre qu'une mémoire tampon soit libérée, qu'un fichier de données soit lu ou qu'un journal soit écrit. Plus une session attend les ressources, moins elle s'exécute sur leCPU.

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 :

Haut SQL

Lorsque les événements d'attente indiquent des goulots d'étranglement, le haut SQL indique les requêtes qui 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 SQL requêtes qui contribuent au chargement 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.