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\$1connexion
L'événement `io/socket/sql/client_connection` se produit lorsqu'un thread gère une nouvelle connexion.
**Topics**
+ [Versions de moteur prises en charge](#ams-waits.client-connection.context.supported)
+ [Contexte](#ams-waits.client-connection.context)
+ [Causes probables de l'augmentation du nombre d'événements d'attente](#ams-waits.client-connection.causes)
+ [Actions](#ams-waits.client-connection.actions)
## 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, veuillez consulter [Serveur MySQL (mysqld)](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.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.
**Topics**
+ [Identifier les sessions et requêtes problématiques](#ams-waits.client-connection.actions.identify-queries)
+ [Suivre les bonnes pratiques relatives à la gestion des connexions](#ams-waits.client-connection.actions.manage-connections)
+ [Augmenter l'échelle de votre instance en cas de limitation des ressources](#ams-waits.client-connection.upgrade)
+ [Vérifier les hôtes et les utilisateurs principaux](#ams-waits.client-connection.top-hosts)
+ [Interroger les tables performance\$1schema](#ams-waits.client-connection.perf-schema)
+ [Vérifiez l'état des threads de vos requêtes](#ams-waits.client-connection.thread-states)
+ [Auditer vos demandes et requêtes](#ams-waits.client-connection.auditing)
+ [Grouper vos connexions de base de données](#ams-waits.client-connection.pooling)
### 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](https://aws.amazon.com/blogs/database/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 console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Performance Insights**.
1. Sélectionnez votre instance DB.
1. Dans **Database load (Charge de base de données)**, choisissez **Slice by wait (Tranche par attente)**.
1. 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 :
+ Utiliser le regroupement des connexions
Vous pouvez augmenter progressivement le nombre de connexions au fil de vos besoins. Pour plus d'informations, consultez le livre blanc [Manuel de l'administrateur de base de données Amazon Aurora MySQL](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
+ Utilisez un nœud de lecteur pour redistribuer le trafic en lecture seule.
Pour plus d’informations, consultez [Réplicas Aurora](Aurora.Replication.md#Aurora.Replication.Replicas) et [Connexions de point de terminaison Amazon Aurora](Aurora.Overview.Endpoints.md).
### 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 une utilisation élevée du processeur.
+ Réseau
Vérifiez s'il y a une augmentation de la valeur des CloudWatch métriques `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, veuillez consulter [Classes d'instances de base de données Amazon Aurora](Concepts.DBInstanceClass.md).
+ Mémoire libérable
Vérifiez s'il y a une baisse de la CloudWatch métrique`FreeableMemory`. 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](USER_Monitoring.OS.md).
### 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](USER_PerfInsights.UsingDashboard.md).
### Interroger les tables performance\$1schema
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 requêtes et des requêtes provenant des comptes utilisateurs, utilisez AuroraAurora 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](AuroraMySQL.Auditing.md).
### 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. Le proxy RDS 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, veuillez consulter [Proxy Amazon RDS pour Aurora](rds-proxy.md).