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.
envoi de données
L'état de thread sending data indique qu'un thread lit et filtre les lignes d'une requête afin de déterminer l'ensemble de résultats qui convient. Le nom est trompeur car il implique que l'état transfère des données, sans collecter ni préparer les données à envoyer ultérieurement.
Rubriques
Versions de moteur prises en charge
Ces informations relatives aux états de thread sont prises en charge dans les versions suivantes :
-
Aurora MySQL versions 2 à 2.09.2
Contexte
De nombreux états de thread sont de courte durée. Les opérations intervenant pendant sending
data ont tendance à effectuer un grand nombre de lectures de disque ou de cache. Par conséquent, sending data est souvent l'état le plus long au cours de la durée de vie d'une requête donnée. Cet état apparaît lorsqu'Aurora MySQL effectue les opérations suivantes :
-
Lecture et traitement de lignes pour une instruction
SELECT -
Exécution d'un grand nombre de lectures à partir d'un disque ou d'une mémoire
-
Exécution d'une lecture complète de toutes les données d'une requête spécifique
-
Lecture de données à partir d'une table, d'un index ou du travail d'une procédure stockée
-
Tri, regroupement ou classement des données
Après que l'état sending data a terminé de préparer les données, l'état de thread writing to net indique le renvoi des données au client. En règle générale, writing to net est uniquement capturé lorsque l'ensemble de résultats est très volumineux ou qu'une importante latence réseau ralentit le transfert.
Causes probables de l'augmentation du nombre d'événements d'attente
L'apparition de sending data n'indique pas en soi un problème. Si les performances sont médiocres et que les instances de sending data se multiplient, les causes les plus probables sont les suivantes.
Requête inefficace
Dans la plupart des cas, cet état découle d'une requête qui n'utilise pas d'index approprié pour trouver l'ensemble de résultats d'une requête spécifique. Par exemple, considérez une requête lisant une table de 10 millions d'enregistrements correspondant à l'ensemble des commandes passées en Californie, où la colonne d'état n'est pas indexée ou mal indexée. Dans ce dernier cas, l'index peut exister, mais l'optimiseur l'ignore en raison de sa faible cardinalité.
Configuration sous-optimale du serveur
Si plusieurs requêtes apparaissent dans l'état sending data, le serveur de base de données peut être mal configuré. Plus précisément, le serveur peut se heurter aux problèmes suivants :
-
Le serveur de base de données ne dispose pas d'une capacité de calcul suffisante : I/O disque, type et vitesse de disque, processeur ou nombre de processeurs.
-
Le serveur consomme beaucoup de ressources allouées, telles que le groupe de mémoires tampons InnoDB pour les tables InnoDB ou le tampon de clé pour les tables MyIsam.
-
Les paramètres de mémoire par thread tels que
sort_buffer,read_bufferetjoin_bufferconsomment plus de RAM que nécessaire, privant le serveur physique de ressources mémoire.
Actions
De manière générale, nous vous conseillons de rechercher les requêtes qui renvoient un grand nombre de lignes en vérifiant le schéma de performance. Si les requêtes de journalisation n'utilisant pas d'index sont activées, vous pouvez également examiner les résultats des journaux lents.
Rubriques
Activer le schéma de performance, le cas échéant
Performance Insights signale les états de thread uniquement si les instruments du schéma de performance ne sont pas activés. Lorsque les instruments du schéma de performance sont activés, Performance Insights signale plutôt les événements d'attente. Les instruments du schéma de performance fournissent des informations supplémentaires et de meilleurs outils pour examiner les possibles problèmes de performances. Par conséquent, nous vous recommandons d'activer le schéma de performance. Pour de plus amples informations, veuillez consulter Présentation du schéma de performance pour Performance Insights on Aurora My SQL My SQL.
Examiner les paramètres de mémoire
Examinez les paramètres de mémoire des groupes de mémoires tampons principaux. Assurez-vous que ces groupes de mémoires tampons sont correctement dimensionné pour la charge de travail. Si votre base de données utilise plusieurs instances de groupe de mémoires tampons, assurez-vous qu'elles ne sont pas divisées en petits groupes de mémoires tampons. Les threads ne peuvent utiliser qu'un seul groupe de mémoires tampons à la fois.
Assurez-vous que les paramètres de mémoire suivants utilisés pour chaque thread sont correctement dimensionnés :
-
read_buffer
-
read_rnd_buffer
-
sort_buffer
-
join_buffer
-
binlog_cache
Sauf raison spécifique de les modifier, utilisez les valeurs par défaut des paramètres.
Examiner les plans d'explication de l'utilisation d'index
Pour les requêtes dans l'état de thread sending data, examinez le plan pour déterminer si des index appropriés sont utilisés. Si une requête n'utilise pas d'index utile, envisagez d'ajouter des indicateurs tels que USE INDEX ou FORCE
INDEX. Les indicateurs peuvent considérablement augmenter ou diminuer le délai nécessaire à l'exécution d'une requête et par conséquent, ajoutez-les à bon escient.
Vérifier le volume de données renvoyées
Vérifiez les tables interrogées et la quantité de données qu'elles contiennent. Certaines de ces données peuvent-elles être archivées ? Très souvent, de piètres délai d'exécution des requêtes ne relèvent pas du plan des requête, mais du volume de données à traiter. De nombreux développeurs ajoutent facilement des données à une base de données, mais rares sont ceux à prendre en compte le cycle de vie des jeux de données lors des phases de conception et de développement.
Recherchez les requêtes qui fonctionnent bien dans les bases de données à faible volume, mais qui fonctionnent nettement moins bien dans votre système actuel. Parfois, les développeurs qui conçoivent des requêtes spécifiques ne réalisent pas que ces requêtes renvoient 350 000 lignes. Les développeurs ont peut-être développé les requêtes dans un environnement à faible volume avec des jeux de données plus petits que ceux des environnements de production.
Vérifier les problèmes de simultanéité
Vérifiez si plusieurs requêtes de même type sont exécutées en même temps. Certaines formes de requêtes s'exécutent efficacement lorsqu'elles sont exécutées seules. Toutefois, si des formes de requête similaires sont exécutées ensemble ou à un volume élevé, elles peuvent entraîner des problèmes de simultanéité. Ces problèmes surviennent souvent lorsque la base de données utilise des tables temporaires pour afficher les résultats. Un niveau d'isolement restrictif des transactions peut également entraîner des problèmes de simultanéité.
Si les tables sont lues et écrites simultanément, la base de données peut utiliser des verrous. Pour mieux identifier les périodes où les performances sont médiocres, examinez l'utilisation des bases de données via des processus par lots à grande échelle. Pour voir les verrous et restaurations récents, examinez la sortie de la commande SHOW ENGINE INNODB STATUS.
Vérifier la structure de vos requêtes
Vérifiez si les requêtes capturées depuis ces états utilisent des sous-requêtes. Ce type de requête entraîne souvent de mauvaises performances, car la base de données compile les résultats en interne, puis les remplace à nouveau dans la requête pour restituer les données. Ce processus relève d'une étape supplémentaire pour la base de données. Bien souvent, cette étape peut entraîner de mauvaises performances dans des conditions de chargement hautement simultanées.
Vérifiez également si vos requêtes utilisent un grand nombre de clauses ORDER BY et GROUP BY. Au cours de telles opérations, la base de données doit souvent constituer le jeu de données entier en mémoire. Elle doit ensuite classer ou regrouper ces données de manière spécifique avant de les renvoyer au client.
