io/socket/sql/client_connexion - Amazon Aurora
Versions de moteur prises en chargeContexteCauses probables de l'augmentation du nombre d'événements d'attenteActions

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/socket/sql/client_connexion

L'événement io/socket/sql/client_connection se produit lorsqu'un thread gère une nouvelle connexion.

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 My SQL versions 2 et 3

Contexte

L'événement io/socket/sql/client_connection indique que mysqld est occupé à créer des threads pour gérer les nouvelles connexions client entrantes. Dans ce scénario, le traitement de la maintenance des nouvelles demandes de connexion client ralentit alors que les connexions attendent l'attribution du thread. Pour de plus amples informations, veuillez consulter Serveur MySQL (mysqld).

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

Un événement de ce type trop fréquent peut révéler un problème de performances dont les causes sont généralement les suivantes :

  • Il y a une augmentation soudaine du nombre de nouvelles connexions utilisateur entre l'application et votre RDS instance Amazon.

  • Votre instance de base de données ne peut pas traiter de nouvelles connexions car le réseau ou la mémoire sont limités. CPU

Actions

Si io/socket/sql/client_connection domine l'activité de la base de données, cela n'indique pas nécessairement un problème de performances. Dans une base de données active, un événement d'attente est toujours en tête. N'intervenez qu'en cas de dégradation des performances. Nous recommandons différentes actions selon les causes de votre événement d'attente.

Identifier les sessions et requêtes problématiques

Si votre instance de base de données se heure à un goulet d'étranglement, votre première tâche consiste à rechercher les sessions et les requêtes qui en sont à l'origine. Pour un article de blog utile, consultez Analyze Amazon Aurora My SQL Workloads avec Performance Insights.

Pour identifier les sessions et les requêtes à l'origine d'un goulet d'étranglement

  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. Sélectionnez votre instance DB.

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

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

    Les requêtes situées en haut de la liste imposent la charge la plus élevée sur la base de données.

Suivre les bonnes pratiques relatives à la gestion des connexions

Pour gérer vos connexions, envisagez les stratégies suivantes :

Augmenter l'échelle de votre instance en cas de limitation des ressources

Recherchez des exemples de limitation dans les ressources suivantes :

  • CPU

    Vérifiez vos CloudWatch statistiques Amazon pour détecter un taux CPU d'utilisation élevé.

  • Réseau

    Vérifiez s'il y a une augmentation de la valeur des CloudWatch métriques network receive throughput etnetwork transmit throughput. Si votre instance a atteint la limite de bande passante réseau pour votre classe d'instance, envisagez de la redimensionner vers un type de classe d'instance supérieur. RDS Pour de plus amples informations, veuillez consulter Classes d'instances de base de données Amazon Aurora.

  • Mémoire libérable

    Vérifiez qu'il n'y a pas de baisse de la CloudWatch métriqueFreeableMemory. Pensez également à activer la surveillance améliorée. Pour de plus amples informations, veuillez consulter Surveillance des métriques du système d'exploitation à l'aide de la Surveillance améliorée.

Vérifier les hôtes et les utilisateurs principaux

Utilisez Performance Insights pour vérifier les hôtes et les utilisateurs principaux. Pour de plus amples informations, veuillez consulter Analyse des métriques à l'aide du tableau de bord de Performance Insights.

Interroger les tables performance_schema

Pour obtenir un comptage précis des connexions actuelles et totales, interrogez les tables performance_schema. Cette technique vous permet d'identifier l'utilisateur ou l'hôte source responsable de la création d'un grand nombre de connexions. Par exemple, interrogez les tables performance_schema comme suit.

SELECT * FROM performance_schema.accounts;
SELECT * FROM performance_schema.users;
SELECT * FROM performance_schema.hosts;

Vérifiez l'état des threads de vos requêtes

Si votre problème de performances persiste, vérifiez l'état des threads de vos requêtes. Dans le client mysql, exécutez la commande suivante.

show processlist;

Auditer vos demandes et requêtes

Pour vérifier la nature des demandes et des requêtes provenant des comptes utilisateurs, utilisez AuroraAurora My SQL Advanced Auditing. Pour en savoir plus sur l'activation de l'audit, consultez Utilisation de l'audit avancé avec un cluster Amazon Aurora My SQL DB.

Grouper vos connexions de base de données

Envisagez d'utiliser Amazon RDS Proxy pour la gestion des connexions. En utilisant le RDS proxy, vous pouvez autoriser vos applications à regrouper et à partager des connexions à des bases de données afin d'améliorer leur capacité à évoluer. RDS Le proxy améliore la résilience des applications face aux défaillances de base de données en se connectant automatiquement à une instance de base de données de secours tout en préservant les connexions des applications. Pour de plus amples informations, veuillez consulter Proxy Amazon RDS pour Aurora.