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.
Rubriques
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 MySQL version 2
Dans les versions antérieures aux versions 2.07.7, 2.09.3 et 2.10.2, cet événement d'attente inclut par erreur le temps d'inactivité.
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
-
Le client peut être soumis à une pression exercée sur l'UC, la mémoire ou à une saturation du réseau. Une augmentation de la charge exercée sur le client retarde la réception des données du cluster de bases de données Aurora MySQL.
- Latence réseau accrue
-
La latence réseau peut être accrue entre le cluster de bases de données Aurora MySQL et le client. 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.
Rubriques
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 les requêtes SQL responsables d'une charge élevée
Connectez-vous à l'AWS Management Console et ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/
. -
Dans le volet de navigation, choisissez Performance Insights.
-
Choisissez une instance de base de données. Le tableau de bord Performance Insights s'affiche pour cette instance de base de données.
-
Dans le graphique Database load (Charge de base de données), choisissez Slice by wait (Tranche par attente).
-
Au bas de la page, choisissez Top SQL (Principaux éléments SQL).
Le graphique répertorie les requêtes SQL 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 de la résolution des problèmes à l'aide de Performance Insights, consultez le billet de blog AWS Database Amazon Aurora MySQL Workloads with Performance Insights
Mettre à l'échelle la classe d'instance de base de données
Vérifiez toute augmentation des métriques Amazon CloudWatch liées au débit réseau, notamment NetworkReceiveThroughput et NetworkTransmitThroughput. 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 la surveillance des métriques Amazon CloudWatch, consultez Afficher 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 bases 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.
Utiliser le modificateur SQL_BUFFER_RESULT
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 en savoir plus, consultez SELECT Statement
