io/socket/sql/client_connection - 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_connection

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 MySQL 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, consultez Serveur MySQL (mysqld).

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

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

  • Le nombre de nouvelles connexions utilisateur entre l'application et votre instance Amazon RDS augmente soudainement.

  • Votre instance de base de données n'est pas en mesure de traiter de nouvelles connexions, car le réseau, le processeur ou la mémoire sont limités.

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 billet de blog particulièrement utile, consultez Analyze Amazon Aurora MySQL Workloads with Performance Insights.

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

  1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à 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 (Principaux éléments 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 métriques Amazon CloudWatch en termes d'utilisation élevée de l'UC.

  • Réseau

    Vérifiez toute augmentation des métriques CloudWatch network receive throughput et network transmit throughput. Si votre instance a atteint la limite de bande passante réseau pour votre classe d'instance, pensez à augmenter l'échelle de votre instance RDS vers un type de classe d'instance supérieur. Pour de plus amples informations, consultez Classes d’instance de base de données Amazon Aurora.

  • Mémoire libérable

    Vérifiez une éventuelle baisse de la métrique CloudWatch FreeableMemory. Pensez également à activer la surveillance améliorée. Pour de plus amples informations, consultez 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, consultez 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 de comptes utilisateurs, utilisez Aurora MySQL Advanced Auditing. Pour en savoir plus sur l'activation de l'audit, consultez Utilisation de l’Audit avancé avec un cluster de bases de données Amazon Aurora MySQL.

Grouper vos connexions de base de données

Pensez à utiliser Amazon RDS Proxy pour gérer les connexions. RDS Proxy vous permet d'autoriser vos applications à grouper et à partager des connexions de bases de données pour améliorer leur capacité de mise à l'échelle. RDS Proxy rend les applications plus résistantes aux échecs de base de données en les connectant automatiquement à une instance de base de données de secours tout en préservant les connexions des applications. Pour de plus amples informations, consultez Proxy Amazon RDS pour Aurora.