Aide-mémoire sur les performances de MySQL

MySQL est vaste et comporte de nombreux domaines à optimiser et à modifier pour obtenir les performances souhaitées. Certaines modifications peuvent être effectuées dynamiquement, d'autres nécessitent un redémarrage du serveur. Il est assez courant de trouver une installation MySQL avec une configuration par défaut, bien que cette dernière puisse ne pas être appropriée en soi à partir de votre charge de travail et de votre configuration.

Voici les domaines clés de MySQL que j'ai tirés de différentes sources d'experts du monde MySQL, ainsi que de nos propres expériences ici chez Manynines. Ce blog servira de feuille de triche pour ajuster les performances et rendre votre MySQL encore meilleur :-)

Examinons-les en décrivant les domaines clés de MySQL.

Variables système

MySQL a beaucoup de variables que vous pouvez envisager de changer. Certaines variables sont dynamiques, ce qui signifie qu'elles peuvent être définies à l'aide de l'instruction SET. D'autres nécessitent un redémarrage du serveur, après avoir été définis dans le fichier de configuration (par exemple, /etc/my.cnf, etc/mysql/my.cnf). Cependant, je vais passer en revue les éléments courants qu'il est assez courant de régler pour optimiser le serveur.

sort_buffer_size

Cette variable contrôle la taille de votre tampon de tri de fichiers, ce qui signifie que chaque fois qu'une requête doit trier les lignes, la valeur de cette variable est utilisée pour limiter la taille qui doit être allouée. Notez que cette variable est traitée par requête (ou par connexion), ce qui signifie que ce serait une mémoire gourmande lorsque vous la définissez plus haut et si vous avez plusieurs connexions qui nécessitent le tri de vos lignes. Cependant, vous pouvez surveiller vos besoins en vérifiant la variable d'état globale Sort_merge_passes. Si cette valeur est élevée, vous devez envisager d'augmenter la valeur de la variable système sort_buffer_size. Sinon, amenez-le à la limite modérée dont vous avez besoin. Si vous le définissez trop bas ou si vous avez des requêtes volumineuses à traiter, l'effet du tri de vos lignes peut être plus lent que prévu car les données sont récupérées de manière aléatoire lors d'explorations de disque. Cela peut entraîner une dégradation des performances. Cependant, il est préférable de corriger vos requêtes. Sinon, si votre application est conçue pour extraire des requêtes volumineuses et nécessite un tri, il est efficace d'utiliser des outils qui gèrent la mise en cache des requêtes comme Redis. Par défaut, dans MySQL 8.0, la valeur actuelle définie est de 256 Ko. Définissez ceci en conséquence uniquement lorsque vous avez des requêtes qui utilisent ou appellent fortement des tris.

read_buffer_size

La documentation MySQL mentionne que pour chaque requête qui effectue une analyse séquentielle d'une table, elle alloue un tampon de lecture. La variable système read_buffer_size détermine la taille du tampon. Elle est également utile pour MyISAM, mais cette variable affecte également tous les moteurs de stockage. Pour les tables MEMORY, il est utilisé pour déterminer la taille du bloc mémoire.

Fondamentalement, chaque thread qui effectue une analyse séquentielle d'une table MyISAM alloue un tampon de cette taille (en octets) pour chaque table qu'il analyse. Cela s'applique également à tous les moteurs de stockage (y compris InnoDB), il est donc utile pour les requêtes qui trient les lignes à l'aide de ORDER BY et mettent en cache ses index dans un fichier temporaire. Si vous effectuez de nombreuses analyses séquentielles, insérez en masse dans des tables de partition, mettez en cache les résultats des requêtes imbriquées, puis envisagez d'augmenter sa valeur. La valeur de cette variable doit être un multiple de 4 Ko. S'il est défini sur une valeur qui n'est pas un multiple de 4 Ko, sa valeur sera arrondie au multiple de 4 Ko le plus proche. Tenez compte du fait que définir cette valeur sur une valeur plus élevée consommera une grande partie de la mémoire de votre serveur. Je suggère de ne pas l'utiliser sans une analyse comparative et une surveillance appropriées de votre environnement.

read_rnd_buffer_size

Cette variable traite de la lecture des lignes d'une table MyISAM dans un ordre trié suite à une opération de tri par clé, les lignes sont lues via ce tampon pour éviter les recherches de disque. La documentation indique que lors de la lecture de lignes dans une séquence arbitraire ou à partir d'une table MyISAM dans un ordre trié après une opération de tri par clé, les lignes sont lues via ce tampon (et déterminées via cette taille de tampon) pour éviter les recherches de disque. Définir la variable sur une valeur élevée peut améliorer considérablement les performances de ORDER BY. Cependant, il s'agit d'un tampon alloué à chaque client, vous ne devez donc pas définir la variable globale sur une valeur élevée. Au lieu de cela, modifiez la variable de session uniquement à partir des clients qui doivent exécuter des requêtes volumineuses. Cependant, vous devez tenir compte du fait que cela ne s'applique pas à MariaDB, en particulier lorsque vous tirez parti du MRR. MariaDB utilise mrr_buffer_size tandis que MySQL utilise read_buffer_size read_rnd_buffer_size.

join_buffer_size

Par défaut, la valeur est de 256K. La taille minimale de la mémoire tampon utilisée pour les balayages d'index simple, les balayages d'index de plage et les jointures qui n'utilisent pas d'index et effectuent donc des balayages de table complets. Également utilisé par l'optimisation BKA (qui est désactivée par défaut). Augmentez sa valeur pour obtenir des jointures complètes plus rapides lorsque l'ajout d'index n'est pas possible. La mise en garde peut toutefois être liée à des problèmes de mémoire si vous définissez ce paramètre trop haut. N'oubliez pas qu'un tampon de jointure est alloué pour chaque jointure complète entre deux tables. Pour une jointure complexe entre plusieurs tables pour lesquelles les index ne sont pas utilisés, plusieurs tampons de jointure peuvent être nécessaires. Il est préférable de laisser bas globalement et de définir haut dans les sessions (en utilisant la syntaxe SET SESSION) qui nécessitent des jointures complètes volumineuses. Sur les plates-formes 64 bits, Windows tronque les valeurs supérieures à 4 Go à 4 Go-1 avec un avertissement.

max_heap_table_size

Il s'agit de la taille maximale en octets pour laquelle les tables MEMORY créées par l'utilisateur sont autorisées à croître. Ceci est utile lorsque votre application traite des tables de moteur de stockage MEMORY. La définition de la variable pendant que le serveur est actif n'a aucun effet sur les tables existantes à moins qu'elles ne soient recréées ou modifiées. Le plus petit de max_heap_table_size et tmp_table_size limite également les tables internes en mémoire. Cette variable est également associée à tmp_table_size pour limiter la taille des tables internes en mémoire (ceci diffère des tables créées explicitement en tant que Engine=MEMORY car elle s'applique uniquement à max_heap_table_size), la valeur la plus petite étant appliquée entre les deux.

tmp_table_size

La plus grande taille pour les tables temporaires en mémoire (pas les tables MEMORY) bien que si max_heap_table_size est plus petit, la limite inférieure s'appliquera. Si une table temporaire en mémoire dépasse la limite, MySQL la convertit automatiquement en une table temporaire sur disque. Augmentez la valeur de tmp_table_size (et max_heap_table_size si nécessaire) si vous effectuez de nombreuses requêtes GROUP BY avancées et que vous disposez d'un espace mémoire important. Vous pouvez comparer le nombre de tables temporaires internes sur disque créées au nombre total de tables temporaires internes créées en comparant les valeurs des variables Created_tmp_disk_tables et Created_tmp_tables. Dans ClusterControl, vous pouvez surveiller cela via Tableau de bord -> Graphique des objets temporaires.

table_open_cache

Vous pouvez augmenter la valeur de cette variable si vous avez un grand nombre de tables fréquemment consultées dans votre ensemble de données. Il sera appliqué pour tous les threads, c'est-à-dire par connexion. La valeur indique le nombre maximal de tables que le serveur peut garder ouvertes dans une instance de cache de table. Bien que l'augmentation de cette valeur augmente le nombre de descripteurs de fichiers requis par mysqld, vous pouvez également envisager de vérifier votre valeur open_files_limit ou de vérifier la taille de la limite SOFT et HARD définie dans votre système d'exploitation *nix. Vous pouvez surveiller cela si vous devez augmenter le cache de table en vérifiant la variable d'état Opened_tables. Si la valeur de Opened_tables est grande et que vous n'utilisez pas souvent FLUSH TABLES (ce qui force simplement la fermeture et la réouverture de toutes les tables), vous devez alors augmenter la valeur de la variable table_open_cache. Si vous avez une petite valeur pour table_open_cache et qu'un grand nombre de tables sont fréquemment consultées, cela peut affecter les performances de votre serveur. Si vous remarquez de nombreuses entrées dans la liste de processus MySQL avec le statut "Ouvrir des tables" ou "Fermer des tables", il est temps d'ajuster la valeur de cette variable, mais prenez note de la mise en garde mentionnée précédemment. Dans ClusterControl, vous pouvez vérifier cela sous Tableaux de bord -> État du cache ouvert de la table ou Tableaux de bord -> Tables ouvertes. Vous pouvez le vérifier ici pour plus d'informations.

table_open_cache_instances

La définition de cette variable contribuerait à améliorer l'évolutivité et, bien sûr, les performances, ce qui réduirait les conflits entre les sessions. La valeur que vous définissez ici limite le nombre d'instances de cache de tables ouvertes. Le cache des tables ouvertes peut être partitionné en plusieurs instances de cache plus petites de taille table_open_cache / table_open_cache_instances . Une session n'a besoin de verrouiller qu'une seule instance pour y accéder pour les instructions DML. Cela segmente l'accès au cache entre les instances, permettant des performances supérieures pour les opérations qui utilisent le cache lorsque de nombreuses sessions accèdent aux tables. (Les instructions DDL nécessitent toujours un verrou sur l'intégralité du cache, mais ces instructions sont beaucoup moins fréquentes que les instructions DML.) Une valeur de 8 ou 16 est recommandée sur les systèmes qui utilisent régulièrement 16 cœurs ou plus.

table_definition_cache

Les définitions de table de cache, c'est-à-dire que c'est là que CREATE TABLE sont mises en cache pour accélérer l'ouverture des tables et une seule entrée par table. Il serait raisonnable d'augmenter la valeur si vous avez un grand nombre de tables. Le cache de définition de table prend moins d'espace et n'utilise pas de descripteurs de fichier, contrairement au cache de table normal. Peter Zaitsev de Percona suggère si vous pouvez essayer le réglage de la formule ci-dessous,

The number of user-defined tables + 10% unless 50K+ tables

Mais notez que la valeur par défaut est basée sur la formule suivante plafonnée à une limite de 2000.

MIN(400 + table_open_cache / 2, 2000)

Donc, si vous avez un plus grand nombre de tables par rapport à la valeur par défaut, il est raisonnable d'augmenter sa valeur. Tenez compte du fait qu'avec InnoDB, cette variable est utilisée comme limite flexible du nombre d'instances de table ouvertes pour le cache du dictionnaire de données. Il appliquera le mécanisme LRU dès qu'il dépassera la valeur courante de cette variable. La limite aide à résoudre les situations dans lesquelles des quantités importantes de mémoire seraient utilisées pour mettre en cache des instances de table rarement utilisées jusqu'au prochain redémarrage du serveur. Par conséquent, les instances de table parent et enfant avec des relations de clé étrangère ne sont pas placées sur la liste LRU et pourraient imposer une limite supérieure à la limite définie par table_definition_cache et ne sont pas sujettes à l'éviction en mémoire pendant LRU. De plus, le table_definition_cache définit une limite souple pour le nombre d'espaces de table fichier par table InnoDB pouvant être ouverts en même temps, qui est également contrôlé par innodb_open_files et en fait, le paramètre le plus élevé entre ces variables est utilisé, si les deux sont définis . Si aucune variable n'est définie, table_definition_cache, qui a une valeur par défaut plus élevée, est utilisée. Si le nombre de descripteurs de fichiers d'espace de table ouverts dépasse la limite définie par table_definition_cache ou innodb_open_files, le mécanisme LRU recherche dans la liste LRU du fichier d'espace de table les fichiers qui sont entièrement vidés et qui ne sont pas en cours d'extension. Ce processus est exécuté chaque fois qu'un nouveau tablespace est ouvert. S'il n'y a pas de tablespaces "inactifs", aucun fichier de tablespace n'est fermé. Alors gardez cela à l'esprit.

max_allowed_packet

Il s'agit de la taille maximale par connexion d'une requête SQL ou d'une ligne renvoyée. La valeur a été augmentée pour la dernière fois dans MySQL 5.6. Cependant, dans MySQL 8.0 (au moins sur 8.0.3), la valeur par défaut actuelle est de 64 Mio. Vous pouvez envisager d'ajuster cela si vous avez de grandes lignes BLOB qui doivent être extraites (ou lues), sinon vous pouvez laisser ces paramètres par défaut avec 8.0 mais dans les anciennes versions, la valeur par défaut est de 4 MiB, vous pouvez donc vous en occuper au cas où vous rencontrer l'erreur ER_NET_PACKET_TOO_LARGE. Le plus grand paquet possible pouvant être transmis vers ou depuis un serveur ou un client MySQL 8.0 est de 1 Go.

max_connexions

Il s'agit du nombre de connexions autorisées pour votre serveur MySQL. Si vous découvrez l'erreur dans MySQL "Trop de connexions", vous pouvez envisager de la définir plus haut. Par défaut, la valeur de 151 n'est pas suffisante, surtout sur une base de données de production, et compte tenu du fait que vous disposez de plus de ressources du serveur (ne gaspillez pas les ressources de votre serveur, surtout s'il s'agit d'un serveur MySQL dédié). Cependant, vous devez avoir suffisamment de descripteurs de fichiers, sinon vous en manquerez. Dans ce cas, envisagez d'ajuster vos limites SOFT et HARD de vos systèmes d'exploitation *nix et définissez une valeur plus élevée de open_files_limit dans MySQL (5000 est la limite par défaut). Tenez compte du fait qu'il est très fréquent que l'application ne ferme pas correctement les connexions à la base de données, et la définition d'un max_connections élevé peut entraîner une certaine inactivité ou une charge élevée de votre serveur. L'utilisation d'un pool de connexions au niveau de l'application peut aider à résoudre le problème ici.

thread_cache_size

Il s'agit du cache pour empêcher la création excessive de threads. Lorsqu'un client se déconnecte, les threads du client sont mis dans le cache s'il y a moins de threads thread_cache_size. Les demandes de threads sont satisfaites en réutilisant les threads extraits du cache si possible, et ce n'est que lorsque le cache est vide qu'un nouveau thread est créé. Cette variable peut être augmentée pour améliorer les performances si vous avez beaucoup de nouvelles connexions. Normalement, cela ne fournit pas une amélioration notable des performances si vous avez une bonne implémentation de thread. Cependant, si votre serveur voit des centaines de connexions par seconde, vous devez normalement définir thread_cache_size suffisamment haut pour que la plupart des nouvelles connexions utilisent des threads en cache. En examinant la différence entre les variables d'état Connections et Threads_created, vous pouvez voir l'efficacité du cache de threads. En utilisant la formule indiquée dans la documentation, 8 + (max_connections / 100) est suffisant.

query_cache_size

Pour certaines configurations, cette variable est leur pire ennemi. Pour certains systèmes soumis à une charge élevée et occupés par des lectures élevées, cette variable vous enlisera. Il y a eu des points de repère qui ont été bien testés, par exemple, Percona. Cette variable doit être définie sur 0 avec query_cache_type =0 également pour la désactiver. La bonne nouvelle dans MySQL 8.0 est que l'équipe MySQL a cessé de le prendre en charge, car cette variable peut réellement causer des problèmes de performances. Je dois convenir sur leur blog qu'il est peu probable qu'il améliore la prévisibilité des performances. Si vous êtes engagé à utiliser la mise en cache des requêtes, je vous suggère d'utiliser Redis ou ProxySQL.

Moteur de stockage - InnoDB

InnoDB est un moteur de stockage conforme à ACID avec diverses fonctionnalités à offrir ainsi que la prise en charge des clés étrangères (intégrité référentielle déclarative). Cela a beaucoup de choses à dire ici, mais certaines variables à prendre en compte pour le réglage :

innodb_buffer_pool_size

Cette variable agit comme un tampon de clé de MyISAM mais elle a beaucoup de choses à offrir. Étant donné qu'InnoDB s'appuie fortement sur le pool de mémoire tampon, vous devriez envisager de définir cette valeur généralement sur 70 % à 80 % de la mémoire de votre serveur. Il est également avantageux que vous ayez un espace mémoire plus grand que votre ensemble de données et que vous définissiez une valeur plus élevée pour votre pool de mémoire tampon, mais pas trop. Dans ClusterControl, cela peut être surveillé à l'aide de notre graphique Dashboards -> InnoDB Metrics -> InnoDB Buffer Pool Pages. Vous pouvez également surveiller cela avec SHOW GLOBAL STATUS en utilisant les variables Innodb_buffer_pool_pages*.

innodb_buffer_pool_instances

Pour votre charge de travail de simultanéité, la définition de cette variable peut améliorer la simultanéité et réduire les conflits en tant que différents threads de lecture/écriture sur les pages mises en cache. Le minimum d'innodb_buffer_pool_instances doit être compris entre 1 (minimum) et 64 (maximum). Chaque page qui est stockée ou lue à partir du pool de mémoire tampon est affectée à l'une des instances du pool de mémoire tampon de manière aléatoire, à l'aide d'une fonction de hachage. Chaque pool de mémoire tampon gère ses propres listes libres, listes de vidage, LRU et toutes les autres structures de données connectées à un pool de mémoire tampon, et est protégé par son propre mutex de pool de mémoire tampon. Notez que cette option ne prend effet que lorsque innodb_buffer_pool_size>=1 Go et que sa taille est divisée entre les instances du pool de mémoire tampon.

innodb_log_file_size

Cette variable est le fichier journal dans un groupe de journaux. La taille combinée des fichiers journaux (innodb_log_file_size * innodb_log_files_in_group) ne peut pas dépasser une valeur maximale légèrement inférieure à 512 Go. Selon Vadim, une plus grande taille de fichier journal est meilleure pour les performances, mais elle présente un inconvénient (important) dont vous devez vous soucier :le temps de récupération après un crash. Vous devez équilibrer le temps de récupération dans le cas rare d'une récupération sur incident par rapport à l'optimisation du débit pendant les pics d'exploitation. Cette limitation peut se traduire par un processus de récupération sur incident 20 fois plus long !

Pour l'élaborer, une valeur plus grande serait bonne pour les journaux de transactions InnoDB et est cruciale pour des performances d'écriture bonnes et stables. Plus la valeur est élevée, moins l'activité de vidage du point de contrôle est requise dans le pool de mémoire tampon, ce qui permet d'économiser les E/S disque. Cependant, le processus de récupération est assez lent une fois que votre base de données a été anormalement arrêtée (crash ou tué, OOM ou accidentel). Idéalement, vous pouvez avoir 1 à 2 Go en production, mais vous pouvez bien sûr ajuster cela. L'analyse comparative de ces changements peut être un grand avantage pour voir comment il fonctionne, en particulier après un crash.

innodb_log_buffer_size

Pour économiser les E/S du disque, InnoDB écrit les données modifiées dans le tampon de journalisation de lt et utilise la valeur de innodb_log_buffer_size ayant une valeur par défaut de 8 Mo. Ceci est particulièrement avantageux pour les transactions volumineuses car il n'est pas nécessaire d'écrire le journal des modifications sur le disque avant la validation de la transaction. Si votre trafic d'écriture est trop élevé (insertions, suppressions, mises à jour), l'augmentation de la taille du tampon permet d'économiser des E/S disque.

innodb_flush_log_at_trx_commit

Lorsque innodb_flush_log_at_trx_commit est défini sur 1, le tampon du journal est vidé à chaque validation de transaction dans le fichier journal sur le disque et fournit une intégrité maximale des données, mais il a également un impact sur les performances. Le définir sur 2 signifie que la mémoire tampon du journal est vidée dans le cache de fichiers du système d'exploitation à chaque validation de transaction. L'implication de 2 est optimale et améliore les performances si vous pouvez assouplir vos exigences ACID et pouvez vous permettre de perdre des transactions pendant la dernière seconde ou les deux dernières en cas de panne du système d'exploitation.

innodb_thread_concurrency

Avec les améliorations apportées au moteur InnoDB, il est recommandé de permettre au moteur de contrôler la concurrence en la gardant à la valeur par défaut (qui est zéro). Si vous rencontrez des problèmes de simultanéité, vous pouvez régler cette variable. Une valeur recommandée est de 2 fois le nombre de processeurs plus le nombre de disques. Sa variable dynamique signifie qu'elle peut être définie sans redémarrer le serveur MySQL.

innodb_flush_method

Cette variable doit cependant être essayée et testée sur le matériel qui vous convient le mieux. Si vous utilisez un RAID avec un cache sauvegardé par batterie, DIRECT_IO aide à soulager la pression des E/S. Les E/S directes ne sont pas mises en cache, ce qui évite la double mise en mémoire tampon avec le pool de mémoire tampon et le cache du système de fichiers. Si votre disque est stocké dans un SAN, O_DSYNC peut être plus rapide pour une charge de travail à lecture intensive avec principalement des instructions SELECT.

innodb_file_per_table

innodb_file_per_table est activé par défaut depuis MySQL 5.6. Ceci est généralement recommandé car cela évite d'avoir un espace de table partagé énorme et cela vous permet de récupérer de l'espace lorsque vous supprimez ou tronquez une table. L'espace de table séparé bénéficie également du schéma de sauvegarde partielle Xtrabackup.

innodb_stats_on_metadata

Cela tente de garder le pourcentage de pages sales sous contrôle, et avant le plugin Innodb, c'était vraiment le seul moyen de régler le vidage du tampon sale. Cependant, j'ai vu des serveurs avec 3% de tampons sales et ils atteignent leur âge maximum au point de contrôle. La façon dont cela augmente le vidage du tampon sale ne s'adapte pas non plus bien aux sous-systèmes à haute io, il double simplement le vidage du tampon sale par seconde lorsque le % de pages sales dépasse ce montant.

innodb_io_capacity

Ce paramètre, malgré tous nos grands espoirs qu'il permettrait à Innodb de mieux utiliser nos E/S dans toutes les opérations, contrôle simplement la quantité de vidage de page sale par seconde (et d'autres tâches en arrière-plan comme la lecture anticipée). Rendez-le plus grand, vous rincez plus par seconde. Cela ne s'adapte pas, il fait simplement autant d'iops chaque seconde s'il y a des tampons sales à vider. Cela éliminera efficacement toute optimisation de la consolidation des E/S si vous avez une charge de travail d'écriture suffisamment faible (c'est-à-dire que les pages sales sont vidées presque immédiatement, nous ferions peut-être mieux de nous passer d'un journal des transactions dans ce cas). Il peut également priver rapidement les lectures et écritures de données dans le journal des transactions si vous le définissez trop haut.

innodb_write_io_threads

Contrôle le nombre de threads qui auront des écritures en cours sur le disque. Je ne sais pas pourquoi cela est toujours utile si vous pouvez utiliser l'AIO natif de Linux. Ceux-ci peuvent également être rendus inutiles par des systèmes de fichiers qui ne permettent pas l'écriture parallèle dans le même fichier par plus d'un thread (en particulier si vous avez relativement peu de tables et/ou utilisez les tablespaces globaux)

innodb_adaptive_flushing

Spécifie s'il faut ajuster dynamiquement le taux de vidage des pages modifiées dans le pool de mémoire tampon InnoDB en fonction de la charge de travail. L'ajustement dynamique du taux de vidage vise à éviter les rafales d'activité d'E/S. Généralement, ceci est activé par défaut. Cette variable, lorsqu'elle est activée, essaie d'être plus intelligente pour un vidage plus agressif en fonction du nombre de pages sales et du taux de croissance du journal des transactions.

innodb_dedicated_server

Cette variable est nouvelle dans MySQL 8.0 qui est appliquée globalement et nécessite un redémarrage de MySQL car ce n'est pas une variable dynamique. Cependant, comme la documentation indique que cette variable ne doit être activée que si votre MySQL s'exécute sur un serveur dédié. Sinon, ne l'activez pas sur un hôte partagé ou partagez les ressources système avec d'autres applications. Lorsque cette option est activée, InnoDB effectuera une configuration automatique de la quantité de mémoire détectée pour les variables innodb_buffer_pool_size, innodb_log_file_size, innodb_flush_method. Le seul inconvénient est que vous ne pouvez pas avoir la possibilité d'appliquer les valeurs souhaitées aux variables détectées mentionnées.

MonISAM

key_buffer_size

InnoDB est maintenant le moteur de stockage par défaut de MySQL, la valeur par défaut pour key_buffer_size peut probablement être réduite à moins que vous n'utilisiez MyISAM de manière productive dans le cadre de votre application (mais qui utilise MyISAM en production maintenant ?). Je suggérerais ici de définir peut-être 1 % de RAM ou 256 Mio au démarrage si vous disposez d'une plus grande mémoire et de dédier la mémoire restante au cache de votre système d'exploitation et au pool de mémoire tampon InnoDB.

Autres dispositions relatives aux performances

slow_query_log

Bien entendu, cette variable ne permet pas de booster votre serveur MySQL. Cependant, cette variable peut vous aider à analyser les requêtes lentes. La valeur peut être définie sur 0 ou OFF pour désactiver la journalisation. Réglez-le sur 1 ou sur ON pour l'activer. La valeur par défaut dépend si l'option --slow_query_log est donnée. La destination de la sortie du journal est contrôlée par la variable système log_output; si cette valeur est NONE, aucune entrée de journal n'est écrite même si le journal est activé. Vous pouvez définir le nom de fichier ou la destination du fichier journal de requête en définissant la variable slow_query_log_file.

long_query_time

Si une requête prend plus de temps que ce nombre de secondes, le serveur incrémente la variable d'état Slow_queries. Si le journal des requêtes lentes est activé, la requête est consignée dans le fichier journal des requêtes lentes. Cette valeur est mesurée en temps réel, et non en temps CPU, de sorte qu'une requête inférieure au seuil sur un système peu chargé peut être supérieure au seuil sur un système fortement chargé. Les valeurs minimale et par défaut de long_query_time sont respectivement 0 et 10. Notez également que si la variable min_examined_row_limit est définie> 0, elle n'enregistrera pas les requêtes même si cela prend trop de temps si le nombre de lignes renvoyées est inférieur à la valeur définie dans min_examined_row_limit.

Pour plus d'informations sur le réglage de votre journalisation lente des requêtes, consultez la documentation ici.

sync_binlog

Cette variable contrôle la fréquence à laquelle MySQL synchronisera les binlogs sur le disque. Par défaut (>=5.7.7), ceci est défini sur 1, ce qui signifie qu'il se synchronisera sur le disque avant que les transactions ne soient validées. Cependant, cela a un impact négatif sur les performances en raison de l'augmentation du nombre d'écritures. Mais c'est le réglage le plus sûr si vous voulez être strictement conforme à ACID avec vos esclaves. Vous pouvez également le définir sur 0 si vous souhaitez désactiver la synchronisation du disque et compter uniquement sur le système d'exploitation pour vider le journal binaire sur le disque de temps en temps. Une valeur supérieure à 1 signifie que le journal binaire est synchronisé sur le disque après que N groupes de validation de journal binaire ont été collectés, où N est> 1.

Vider/Restaurer le pool de tampons

Il est assez courant que votre base de données de production doive se réchauffer après un démarrage/redémarrage à froid. En vidant le pool de mémoire tampon actuel avant un redémarrage, il enregistrerait le contenu du pool de mémoire tampon et une fois qu'il est en place, il rechargera le contenu dans le pool de mémoire tampon. Ainsi, cela évite d'avoir à réchauffer votre base de données pour le cache. Notez que cette version a depuis été introduite dans la version 5.6, mais Percona Server 5.5 l'a déjà disponible, juste au cas où vous vous poseriez la question. Pour activer cette fonctionnalité, définissez les deux variables innodb_buffer_pool_dump_at_shutdown =ON et innodb_buffer_pool_load_at_startup =ON.

Matériel

Nous sommes maintenant en 2019, il y a eu beaucoup de nouvelles améliorations matérielles. En règle générale, il n'y a pas d'exigence stricte selon laquelle MySQL nécessiterait un matériel spécifique, mais cela dépend de ce que vous avez besoin que la base de données fasse. Je suppose que vous ne lisez pas ce blog parce que vous faites un test s'il fonctionne sur un processeur Intel Pentium 200 MHz.

Pour le CPU, les processeurs plus rapides avec plusieurs cœurs seront optimaux pour MySQL dans les versions les plus récentes au moins depuis la 5.6. Les processeurs Xeon/Itanium d'Intel peuvent être coûteux, mais testés pour des plates-formes informatiques évolutives et fiables. Amazon a livré ses instances EC2 fonctionnant sur l'architecture ARM. Bien que je n'aie personnellement pas essayé d'exécuter ou de me souvenir d'avoir exécuté MySQL sur l'architecture ARM, il existe des références qui ont été faites il y a des années. Les processeurs modernes peuvent augmenter et réduire leurs fréquences en fonction de la température, de la charge et des politiques d'économie d'énergie du système d'exploitation. Cependant, il est possible que les paramètres de votre processeur dans votre système d'exploitation Linux soient définis sur un gouverneur différent. Vous pouvez vérifier cela ou définir avec le gouverneur "performance" en procédant comme suit :

echo performance | sudo tee /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_governor

Pour la mémoire, il est très important que votre mémoire soit grande et puisse correspondre à la taille de votre jeu de données. Assurez-vous que vous avez swappiness =1. Vous pouvez le vérifier en vérifiant sysctl ou en vérifiant le fichier dans procfs. Ceci est réalisé en procédant comme suit :

$ sysctl -e vm.swappiness
vm.swappiness = 1

Ou en le réglant sur une valeur de 1 comme suit

$ sudo sysctl vm.swappiness=1
vm.swappiness = 1

Une autre bonne chose à considérer pour votre gestion de la mémoire est d'envisager de désactiver THP (Transparrent Huge Pages). Dans le passé, je me souviens que nous avions rencontré des problèmes étranges avec l'utilisation du processeur et que nous pensions que cela était dû aux E / S du disque. Il s'est avéré que le problème était lié au thread khugepaged du noyau qui alloue de la mémoire de manière dynamique pendant l'exécution. De plus, pendant la défragmentation du noyau, votre mémoire sera rapidement allouée lorsqu'elle sera transmise à THP. La mémoire HugePages standard est pré-allouée au démarrage et ne change pas pendant l'exécution. Vous pouvez vérifier et désactiver cela en procédant comme suit :

$ cat /sys/kernel/mm/transparent_hugepage/enabled
$ echo "never" > /sys/kernel/mm/transparent_hugepage/enabled

Pour Disk, il est important que vous ayez un bon débit. L'utilisation de RAID10 est la meilleure configuration pour une base de données avec une unité de sauvegarde sur batterie. Avec l'avènement des lecteurs flash qui offrent un débit de disque élevé et des E/S disque élevées pour la lecture/écriture, il est important qu'il puisse gérer l'utilisation élevée du disque et les E/S disque.

Système d'exploitation

La plupart des systèmes de production exécutés sur MySQL fonctionnent sur Linux. C'est parce que MySQL a été testé et comparé sur Linux, et semble être la norme de facto pour une installation MySQL. Cependant, bien sûr, rien ne vous empêche de l'utiliser sur la plate-forme Unix ou Windows. Ce serait plus facile si votre plate-forme avait été testée et qu'il y avait une large communauté pour vous aider, au cas où vous rencontriez des problèmes. La plupart des configurations fonctionnent sur les systèmes RHEL/Centos/Fedora et Debian/Ubuntu. Dans AWS, Amazon a son Amazon Linux qui, je le vois, est également utilisé en production par certains.

Le plus important à prendre en compte dans votre configuration est que votre système de fichiers utilise XFS ou Ext4. Bien sûr, il y a des avantages et des inconvénients entre ces deux systèmes de fichiers, mais je n'entrerai pas dans les détails ici. Certains disent que XFS surpasse Ext4, mais il existe également des rapports selon lesquels Ext4 surpasse XFS. ZFS sort également de l'image comme un bon candidat pour un système de fichiers alternatif. Jervin Real (de Percona) a une excellente ressource sur celui-ci, vous pouvez consulter cette présentation lors de la conférence ZFS.

Liens externes

https://developer.okta.com/blog/2015/05/22/tcmalloc

https://www.percona.com/blog/2012/07/05/impact-of-memory-allocators-on-mysql-performance/

https://www.percona.com/live/18/sessions/benchmark-noise-reduction-how-to-configure-your-machines-for-stable-results

https://zfs.datto.com/2018_slides/real.pdf

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/ladbi/disabling-transparent-hugepages.html#GUID-02E9147D-D565-4AF8-B12A-8E6E9F74BEEA