io/aurora_respond_to_client - 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.

io/aurora_respond_to_client

L'événement io/aurora_respond_to_client se produit lorsqu'un thread attend de renvoyer un ensemble de résultats à un client.

Versions de moteur prises en charge

Ces informations relatives aux événements d'attente sont prises en charge pour les versions de moteur suivantes :

  • Aurora Ma SQL version 2

Contexte

L'événement io/aurora_respond_to_client indique qu'un thread attend de renvoyer un ensemble de résultats à un client.

Le traitement des requêtes est terminé et les résultats sont renvoyés au client de l'application. Toutefois, la bande passante réseau sur le cluster de bases de données étant insuffisante, un thread attend de renvoyer l'ensemble de résultats.

Causes probables de l'augmentation du nombre d'événements d'attente

Lorsque l'événement io/aurora_respond_to_client se produit plus souvent qu'à l'accoutumée, indiquant un possible problème de performance, les causes sont généralement les suivantes :

Classe d'instance de base de données insuffisante pour la charge de travail

La classe d'instance de base de données utilisée par le cluster de bases de données ne dispose pas de suffisamment de bande passante réseau pour traiter efficacement la charge de travail.

Ensembles de résultats volumineux

La taille de l'ensemble de résultats renvoyé a augmenté, car la requête renvoie un nombre plus élevé de lignes. L'ensemble de résultats plus volumineux consomme davantage de bande passante réseau.

Charge accrue sur le client

Il peut y avoir CPU une pression, une pression sur la mémoire ou une saturation du réseau sur le client. Une augmentation de la charge sur le client retarde la réception des données du cluster Aurora My SQL DB.

Latence réseau accrue

La latence réseau entre le cluster Aurora My SQL DB et le client peut augmenter. Une latence réseau plus élevée augmente le temps nécessaire au client pour recevoir les données.

Actions

Nous vous recommandons différentes actions en fonction des causes de votre événement d'attente.

Identifier les sessions et les requêtes à l'origine des événements

Vous pouvez utiliser Performance Insights pour afficher les requêtes bloquées par l'événement d'attente io/aurora_respond_to_client. En règle générale, les bases de données à charge modérée à importante présentent des événements d'attente. Les événements d'attente peuvent être acceptables si les performances sont optimales. Si les performances ne sont pas optimales, voyez où la base de données passe le plus de temps. Examinez les événements d'attente qui contribuent à la charge la plus élevée et voyez si vous pouvez optimiser la base de données et l'application afin de réduire ces événements.

Pour rechercher SQL les requêtes responsables d'une charge élevée
  1. Connectez-vous à la RDS console Amazon AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.

  2. Dans le volet de navigation, choisissez Performance Insights.

  3. Choisissez une instance de base de données. Le tableau de bord Performance Insights s'affiche pour cette instance de base de données.

  4. Dans le graphique Database load (Charge de base de données), choisissez Slice by wait (Tranche par attente).

  5. Au bas de la page, choisissez Top SQL.

    Le graphique répertorie les SQL requêtes responsables de la charge. Les requêtes situées en haut de la liste sont les plus responsables. Pour résoudre un goulet d'étranglement, concentrez-vous sur ces instructions.

Pour une présentation utile du dépannage à l'aide de Performance Insights, consultez le billet de blog AWS consacré à la base de données Analyze Amazon Aurora My SQL Workloads with Performance Insights.

Mettre à l'échelle la classe d'instance de base de données

Vérifiez l'augmentation de la valeur des CloudWatch métriques Amazon liées au débit du réseau, telles que NetworkReceiveThroughput etNetworkTransmitThroughput. Si la bande passante réseau de la classe d'instance de base de données est atteinte, vous pouvez mettre à l'échelle la classe d'instance de base de données utilisée par le cluster de bases de données. Une classe d'instance de base de données dotée d'une bande passante réseau plus importante renvoie les données aux clients plus efficacement.

Pour plus d'informations sur le suivi CloudWatch des métriques Amazon, consultezAfficher les métriques dans la RDS console Amazon. Pour plus d'informations sur les classes d'instances de base de données, consultez Classes d'instances de base de données Amazon Aurora. Pour plus d'informations sur la modification d'un cluster de base de données , consultez Modification d'un cluster de bases de données Amazon Aurora.

Vérifier la charge de travail pour trouver des résultats inattendus

Vérifiez la charge de travail sur le cluster de bases de données et assurez-vous qu'elle ne produit pas de résultats inattendus. Par exemple, certaines requêtes peuvent renvoyer un nombre de lignes plus élevé que prévu. Si tel est le cas, vous pouvez utiliser des métriques de compteur Performance Insights telles que Innodb_rows_read. Pour de plus amples informations, veuillez consulter Métrique de compteur de Performance Insights.

Distribuer la charge de travail entre les instances de lecture

Vous pouvez distribuer la charge de travail en lecture seule entre les réplicas Aurora. Vous pouvez procéder à une mise à l'échelle horizontale en ajoutant d'autres réplicas Aurora. Cela peut entraîner une augmentation des limites de bande passante réseau. Pour de plus amples informations, veuillez consulter Clusters de bases de données Amazon Aurora.

Utilisez le RESULT modificateur SQL BUFFER _ _

Vous pouvez ajouter le modificateur SQL_BUFFER_RESULT aux instructions SELECT pour forcer les résultats dans une table temporaire avant qu'ils ne soient renvoyés au client. Ce modificateur facilite la résolution des problèmes de performances lorsque les verrous InnoDB ne sont pas libérés, car des requêtes se trouvent dans l'état d'attente io/aurora_respond_to_client. Pour plus d'informations, consultez la section SELECTDéclaration dans la section Ma SQL documentation.