Concepts essentiels à connaître pour le réglage d'Aurora MySQL

Avant de procéder au réglage de votre base de données Aurora MySQL, vous devez savoir ce que sont les événements d'attente ainsi que les états de thread, et pourquoi ils se produisent. Examinez également l'architecture de base d'Aurora MySQL en termes de mémoire et de disque lorsque vous utilisez le moteur de stockage InnoDB. Un diagramme d'architecture très utile est disponible dans le Manuel de référence MySQL.

Événements d'attente Aurora MySQL

Un événement d'attente désigne une ressource pour laquelle une session est en attente. Par exemple, l'événement d'attente io/socket/sql/client_connection indique qu'un thread gère une nouvelle connexion. Les ressources généralement attendues par une session sont les suivantes :

• Accès monothread à une mémoire tampon, par exemple lorsqu'une session tente de modifier une mémoire tampon

• Ligne verrouillée par une autre session

• Lecture d'un fichier de données

• Écriture de fichier journal

Par exemple, pour répondre à une requête, la session peut effectuer une analyse complète de la table. Si les données ne sont pas déjà en mémoire, la session attend la fin des opérations d'I/O disque. Lorsque les mémoires tampons sont lues en mémoire, la session peut être contrainte d'attendre parce que d'autres sessions accèdent aux mêmes mémoires tampons. La base de données enregistre les attentes à l'aide d'un événement d'attente prédéfini. Ces événements sont regroupés en catégories.

En soi, un événement d'attente n'indique pas un problème de performances. Par exemple, si les données demandées ne sont pas en mémoire, il est nécessaire de les lire sur le disque. Si une session verrouille une ligne pour une mise à jour, une autre session attend que la ligne soit déverrouillée pour pouvoir la mettre à jour. Une validation nécessite d'attendre la fin de l'écriture dans un fichier journal. Les attentes font partie intégrante du fonctionnement normal d'une base de données.

Un grand nombre d'événements d'attente indique généralement un problème de performances. Dans ce cas, vous pouvez utiliser les données des événements d'attente pour déterminer où les sessions passent du temps. Par exemple, si plusieurs heures sont désormais nécessaires à l'exécution d'un rapport qui ne prend habituellement que quelques minutes, vous pouvez identifier les événements d'attente qui contribuent le plus au temps d'attente total. La détermination des causes des principaux événements d'attente peut vous permettre d'apporter des modifications qui auront pour effet d'améliorer les performances. Par exemple, si votre session est en attente sur une ligne qui a été verrouillée par une autre session, vous pouvez mettre fin à la session à l'origine du verrouillage.

États de thread Aurora MySQL

Un état général de thread est une valeur State associée au traitement général des requêtes. Par exemple, 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.

Vous pouvez utiliser les états de thread pour régler Aurora MySQL de la même manière que vous utilisez les événements d'attente. Par exemple, des occurrences fréquentes de sending data indiquent généralement qu'une requête n'utilise pas d'index. Pour plus d'informations sur les états de thread, consultezGeneral Thread States dans le Manuel de référence MySQL.

Lorsque vous utilisez Performance Insights, l'une des conditions suivantes est vraie :

• Le schéma de performance est activé : Aurora MySQL affiche les événements d'attente plutôt que l'état de thread.

• Le schéma de performance n'est pas activé : Aurora MySQL affiche l'état de thread.

Nous vous recommandons de configurer le schéma de performance pour une gestion automatique. Le schéma de performance fournit des informations supplémentaires et de meilleurs outils afin d'examiner les possibles problèmes de performances. Pour en savoir plus, consultez Activation du schéma de performance pour Performance Insights sur Aurora MySQL.

Mémoire Aurora MySQL

Dans Aurora MySQL, les zones mémoire les plus importantes sont le groupe de mémoires tampons et la mémoire tampon de journal.

Rubriques

• Groupe de mémoires tampons

Groupe de mémoires tampons

Le groupe de mémoires tampons correspond à la zone de mémoire partagée dans laquelle Aurora MySQL met en cache les données de table et d'index. Les requêtes peuvent accéder aux données fréquemment utilisées directement depuis la mémoire, sans lecture à partir du disque.

Le groupe de mémoires tampons est structuré sous forme de liste liée de pages. Une page peut contenir plusieurs lignes. Aurora MySQL utilise un algorithme LRU (Last Recently Used) pour faire vieillir les pages du groupe.

Pour en savoir plus, veuillez consulter Buffer Pool dans le Manuel de référence MySQL.

Processus Aurora MySQL

Aurora MySQL utilise un modèle de processus très différent d'Aurora PostgreSQL.

Rubriques

• Serveur MySQL (mysqld)
• Threads
• Groupe de threads

Serveur MySQL (mysqld)

Le serveur MySQL est un processus de système d'exploitation unique nommé mysqld. Le serveur MySQL ne génère pas de processus supplémentaires. Ainsi, une base de données Aurora MySQL utilise mysqld pour effectuer la majeure partie de ses tâches.

Lorsque le serveur MySQL démarre, il écoute les connexions réseau des clients MySQL. Lorsqu'un client se connecte à la base de données, mysqld ouvre un thread.

Threads

Les threads du gestionnaire de connexion associent chaque connexion client à un thread dédié. Ce thread gère l'authentification, exécute des instructions et renvoie les résultats au client. Si nécessaire, le gestionnaire de connexion crée de nouveaux threads.

Le cache de threads correspond à l'ensemble de threads disponibles. Lorsqu'une connexion se termine, MySQL renvoie le thread dans le cache de threads si ce dernier n'est pas plein. La variable système thread_cache_size détermine la taille du cache de threads.

Groupe de threads

Le groupe de threads se compose de plusieurs groupes de threads. Chaque groupe gère un ensemble de connexions client. Lorsqu'un client se connecte à la base de données, le groupe de threads attribue les connexions aux groupes de threads de manière circulaire. Le groupe de threads sépare les connexions et les threads. Il n'existe aucune relation fixe entre les connexions et les threads exécutant les instructions reçues de ces connexions.