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.
Concepts clés pour le réglage des performances des bases de données
DevOpsGuru for RDS part du principe que vous connaissez quelques concepts de performance clés. Pour en savoir plus sur ces concepts, consultez Overview of Performance Insights dans le guide de l'utilisateur Amazon Aurora ou Overview of Performance Insights dans le guide de l'utilisateur Amazon RDS.
Métriques
Une métrique représente un ensemble de points de données ordonnés dans le temps. Envisagez une métrique comme une variable à surveiller et les points de données comme les valeurs de cette variable au fil du temps. Amazon RDS fournit des métriques en temps réel pour la base de données et pour le système d'exploitation (OS) sur lequel votre instance de base de données s'exécute. Vous pouvez consulter toutes les métriques du système et les informations de processus pour vos instances de base de données Amazon RDS sur la console Amazon RDS. DevOpsGuru for RDS surveille et fournit des informations sur certaines de ces métriques. Pour plus d'informations, consultez Surveillance des métriques dans un cluster Amazon Aurora ou Surveillance des métriques dans une instance Amazon Relational Database Service.
Détection des problèmes
DevOpsGuru for RDS utilise des métriques de base de données et de système d'exploitation (OS) pour détecter les problèmes critiques de performance des bases de données, qu'ils soient imminents ou permanents. La détection des problèmes par DevOps Guru for RDS fonctionne principalement de deux manières :
Utilisation de seuils
Utilisation des anomalies
Détecter les problèmes liés aux seuils
Les seuils sont les valeurs limites par rapport auxquelles les mesures surveillées sont évaluées. Vous pouvez considérer un seuil comme une ligne horizontale sur un graphique métrique qui sépare un comportement normal d'un comportement potentiellement problématique. DevOpsGuru for RDS surveille des métriques spécifiques et crée des seuils en analysant les niveaux considérés comme potentiellement problématiques pour une ressource spécifique. DevOpsGuru for RDS crée ensuite des informations dans la console DevOps Guru lorsque de nouvelles valeurs métriques franchissent régulièrement un seuil spécifié sur une période donnée. Les informations contiennent des recommandations visant à éviter tout impact futur sur les performances des bases de données.
Par exemple, DevOps Guru for RDS peut surveiller le nombre de tables temporaires utilisant le disque sur une période de 15 minutes et créer un aperçu lorsque le taux de tables temporaires utilisant le disque par seconde est anormalement élevé. L'augmentation des niveaux d'utilisation des tables temporaires sur disque peut avoir un impact sur les performances de la base de données. En exposant cette situation avant qu'elle ne devienne critique, DevOps Guru for RDS vous aide à prendre des mesures correctives pour éviter les problèmes.
Détecter les problèmes liés aux anomalies
Bien que les seuils constituent un moyen simple et efficace de détecter les problèmes de base de données, ils ne sont pas suffisants dans certains cas. Imaginons le cas où les valeurs métriques augmentent et se transforment régulièrement en comportements potentiellement problématiques en raison d'un processus connu, tel qu'un travail de reporting quotidien. Étant donné que de tels pics sont attendus, la création d'informations et de notifications pour chacun d'entre eux serait contreproductive et conduirait probablement à une lassitude face aux alertes.
Cependant, il est toujours nécessaire de détecter les pics très inhabituels, car des métriques beaucoup plus élevées que les autres ou qui durent beaucoup plus longtemps peuvent représenter de véritables problèmes de performances de base de données. Pour répondre à ce problème, DevOps Guru for RDS surveille certaines métriques afin de détecter les cas où le comportement d'une métrique devient très inhabituel ou anormal. DevOpsGuru rapporte ensuite ces anomalies dans Insights.
Par exemple, DevOps Guru for RDS peut créer un aperçu lorsque la charge de base de données est non seulement élevée, mais qu'elle s'écarte également de manière significative de son comportement habituel, ce qui indique un ralentissement inattendu majeur des opérations de base de données. En reconnaissant uniquement les pics de charge anormaux dans les bases de données, DevOps Guru for RDS vous permet de vous concentrer sur les problèmes réellement importants.
Charge de la base de données
Le concept clé pour le réglage des bases de données est la métrique de charge de base de données (charge de base de données). La charge de base de données représente le niveau d'activité de votre base de données à un moment donné. Une augmentation de la charge de base de données signifie une augmentation de l'activité de la base de données.
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 session en cours d'exécution d'une demande de base de données. 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 soit lue en mémoire avant d'utiliser le processeur pendant la lecture des données de la page.
La DBLoad métrique de Performance Insights est mesurée en nombre moyen de sessions actives (AAS). Pour calculer l'AAS, Performance Insights échantillonne le nombre de sessions actives chaque seconde. Pour une période donnée, l'AAS est le nombre total de sessions actives divisé par le nombre total d'échantillons. Une valeur AAS de 2 signifie qu'en moyenne, 2 sessions étaient actives dans les demandes à un moment donné.
L'activité 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és et les autres sont inactifs. Si 100 commandes ou plus arrivent, les 100 travailleurs exécutent les commandes simultanément. Si vous échantillonnez périodiquement le nombre d'employés actifs sur une période donnée, vous pouvez calculer le nombre moyen d'employés actifs. Le calcul montre qu'en moyenne, N employés sont occupés à traiter des commandes à un moment donné. Si la moyenne était de 50 employés hier et qu'elle est aujourd'hui de 75 employés, cela indique le niveau d'activité 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 augmente.
Pour en savoir plus, consultez la section Chargement de base de données dans le guide de l'utilisateur Amazon Aurora ou Chargement de base de données dans le guide de l'utilisateur Amazon RDS.
Événements d'attente
Un événement d'attente est un type d'instrumentation de base de données qui vous indique la ressource qu'une session de base de données attend pour pouvoir continuer. Lorsque Performance Insights compte les sessions actives pour calculer la charge de la base de données, il enregistre également les événements d'attente à l'origine de l'attente des sessions actives. Cette technique permet à Performance Insights de vous montrer quels événements d'attente contribuent à la charge de la base de données.
Chaque session active est soit en cours d'exécution au niveau du processeur soit en attente. Par exemple, les sessions consomment du processeur lorsqu'elles recherchent de la mémoire, effectuent un calcul ou exécutent du code procédural. Lorsque les sessions ne consomment pas de CPU, elles peuvent attendre la lecture d'un fichier de données ou l'écriture d'un journal. 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 essayez souvent de trouver les ressources que les sessions attendent. Par exemple, deux ou trois événements d'attente peuvent représenter 90 % de la charge de 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 pouvez découvrir la cause de ces attentes, vous pouvez essayer de remédier au problème.
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, il se peut qu'un autre travailleur réapprovisionne actuellement les étagères ou qu'un chariot ne soit pas disponible. ou le système servant à saisir l'état des commandes se montre très lent. Plus le travailleur attend, plus la commande met du temps à être exécutée. L'attente fait naturellement partie du flux de travail de l'entrepôt, mais si le temps d'attente devient excessif, la productivité diminue. 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 sur les événements d'attente dans Amazon Aurora, consultez les sections Tuning with wait events for Aurora PostgreSQL et Tuning with wait events for Aurora MySQL dans le guide de l'utilisateur Amazon Aurora.
Pour plus d'informations sur les événements d'attente dans d'autres bases de données Amazon RDS, consultez la section Tuning with wait events for RDS for PostgreSQL dans le guide de l'utilisateur Amazon RDS.
