Depuis que MySQL a été créé à l'origine pour former MariaDB, il a été largement pris en charge et adopté rapidement par un large public dans la communauté des bases de données open source. À l'origine un remplacement instantané, MariaDB a commencé à se démarquer de MySQL, en particulier avec la sortie de MariaDB 10.2.
Malgré cela, cependant, il n'y a toujours pas de réelle différence révélatrice entre MariaDB et MySQL, car les deux ont des moteurs compatibles et peuvent fonctionner en mode natif les uns avec les autres. Ne soyez donc pas surpris si le réglage de votre configuration MariaDB a une approche similaire à celle du réglage de MySQL.
Ce blog discutera du réglage de MariaDB, en particulier des systèmes fonctionnant dans un environnement Linux.
Optimisation du matériel et du système MariaDB
MariaDB vous recommande d'améliorer votre matériel dans l'ordre de priorité suivant...
Mémoire
La mémoire est le facteur le plus important pour les bases de données car elle vous permet d'ajuster les variables système du serveur. Plus de mémoire signifie des caches de clé et de table plus grands, qui sont stockés dans la mémoire afin que les disques puissent y accéder, d'un ordre de grandeur plus lent, sont ensuite réduits.
Gardez cependant à l'esprit que le simple fait d'ajouter plus de mémoire peut ne pas entraîner d'améliorations drastiques si les variables du serveur ne sont pas définies pour utiliser la mémoire supplémentaire disponible.
L'utilisation de plus de slots RAM sur la carte mère augmente la fréquence du bus, et il y aura plus de latence entre la RAM et le CPU. Cela signifie qu'il est préférable d'utiliser la taille de RAM la plus élevée par emplacement.
Disques
L'accès rapide au disque est essentiel, car c'est finalement là que résident les données. Le chiffre clé est le temps de recherche du disque (une mesure de la vitesse à laquelle le disque physique peut se déplacer pour accéder aux données). Choisissez donc des disques avec un temps de recherche aussi faible que possible. Vous pouvez également ajouter des disques dédiés pour les fichiers temporaires et les journaux de transactions.
Ethernet rapide
Avec les exigences appropriées pour votre bande passante Internet, l'Ethernet rapide signifie qu'il peut avoir une réponse plus rapide aux demandes des clients, un temps de réponse de réplication pour lire les journaux binaires sur les esclaves, des temps de réponse plus rapides sont également très importants, en particulier sur Galera clusters basés sur .
CPU
Bien que les goulots d'étranglement matériels se situent souvent ailleurs, des processeurs plus rapides permettent d'effectuer des calculs plus rapidement et de renvoyer les résultats au client plus rapidement. Outre la vitesse du processeur, la vitesse du bus du processeur et la taille du cache sont également des facteurs importants à prendre en compte.
Configuration de votre planificateur d'E/S de disque
Les planificateurs d'E/S existent pour optimiser les demandes d'accès au disque. Il fusionne les demandes d'E/S vers des emplacements similaires sur le disque. Cela signifie que le lecteur de disque n'a pas besoin de chercher aussi souvent et améliore un temps de réponse global énorme et enregistre les opérations de disque. Les valeurs recommandées pour les performances d'E/S sont noop et deadline.
noop est utile pour vérifier si les décisions de planification d'E/S complexes d'autres planificateurs ne provoquent pas de régressions des performances d'E/S. Dans certains cas, cela peut être utile pour les appareils qui effectuent eux-mêmes la planification des E/S, en tant que stockage intelligent, ou pour les appareils qui ne dépendent pas du mouvement mécanique, comme les SSD. Habituellement, le planificateur d'E/S DEADLINE est un meilleur choix pour ces appareils, mais en raison d'une surcharge moindre, NOOP peut produire de meilleures performances sur certaines charges de travail.
Pour l'échéance, il s'agit d'un ordonnanceur d'E/S orienté latence. Chaque demande d'E/S a un délai assigné. Habituellement, les requêtes sont stockées dans des files d'attente (lecture et écriture) triées par numéros de secteur. L'algorithme DEADLINE maintient deux files d'attente supplémentaires (lecture et écriture) où les demandes sont triées par date limite. Tant qu'aucune requête n'a expiré, la file d'attente "secteur" est utilisée. Si des délais d'attente se produisent, les demandes de la file d'attente « date limite » sont servies jusqu'à ce qu'il n'y ait plus de demandes expirées. Généralement, l'algorithme préfère les lectures aux écritures.
Pour les périphériques PCIe (disques SSD NVMe), ils ont leurs propres grandes files d'attente internes ainsi qu'un service rapide et ne nécessitent pas ou ne bénéficient pas de la configuration d'un planificateur d'E/S. Il est recommandé de ne pas avoir de paramètre de configuration explicite en mode planificateur.
Vous pouvez vérifier les paramètres de votre planificateur avec :
cat /sys/block/${DEVICE}/queue/schedulerPar exemple, cela devrait ressembler à ceci :
cat /sys/block/sda/queue/scheduler
[noop] deadline cfqPour le rendre permanent, modifiez le fichier de configuration /etc/default/grub, recherchez la variable GRUB_CMDLINE_LINUX et ajoutez l'ascenseur comme ci-dessous :
GRUB_CMDLINE_LINUX="elevator=noop"Augmenter la limite des fichiers ouverts
Pour garantir de bonnes performances du serveur, le nombre total de connexions client, de fichiers de base de données et de fichiers journaux ne doit pas dépasser la limite maximale de descripteurs de fichiers sur le système d'exploitation (ulimit -n). Les systèmes Linux limitent le nombre de descripteurs de fichiers qu'un processus peut ouvrir à 1 024 par processus. Sur les serveurs de base de données actifs (en particulier ceux de production), il peut facilement atteindre la limite système par défaut.
Pour augmenter cela, modifiez /etc/security/limits.conf et spécifiez ou ajoutez ce qui suit :
mysql soft nofile 65535
mysql hard nofile 65535Cela nécessite un redémarrage du système. Ensuite, vous pouvez confirmer en exécutant ce qui suit :
$ ulimit -Sn
65535
$ ulimit -Hn
65535Facultativement, vous pouvez le définir via mysqld_safe si vous démarrez le processus mysqld via mysqld_safe,
[mysqld_safe]
open_files_limit=4294967295ou si vous utilisez systemd,
sudo tee /etc/systemd/system/mariadb.service.d/limitnofile.conf <<EOF
[Service]
LimitNOFILE=infinity
EOF
sudo systemctl daemon-reloadConfiguration de Swappiness sur Linux pour MariaDB
Linux Swap joue un grand rôle dans les systèmes de bases de données. Il agit comme votre roue de secours dans votre véhicule, lorsque de vilaines fuites de mémoire interfèrent avec votre travail, la machine ralentira... mais dans la plupart des cas sera toujours utilisable pour finir sa tâche assignée.
Pour appliquer les modifications à votre swappiness, lancez simplement,
sysctl -w vm.swappiness=1Cela se produit de manière dynamique, sans qu'il soit nécessaire de redémarrer le serveur. Pour le rendre persistant, modifiez /etc/sysctl.conf et ajoutez la ligne,
vm.swappiness=1Il est assez courant de définir swappiness=0, mais depuis la sortie de nouveaux noyaux (c'est-à-dire les noyaux> 2.6.32-303), des modifications ont été apportées, vous devez donc définir vm.swappiness=1.
Optimisations du système de fichiers pour MariaDB
Les systèmes de fichiers les plus couramment utilisés dans les environnements Linux exécutant MariaDB sont ext4 et XFS. Il existe également certaines configurations disponibles pour implémenter une architecture utilisant ZFS et BRTFS (comme référencé dans la documentation MariaDB).
En plus de cela, la plupart des configurations de base de données n'ont pas besoin d'enregistrer le temps d'accès aux fichiers. Vous pouvez désactiver cette option lors du montage du volume dans le système. Pour cela, éditez votre fichier /etc/fstab. Par exemple, sur un volume nommé /dev/md2, voici à quoi cela ressemble :
/dev/md2 / ext4 defaults,noatime 0 0Création d'une instance MariaDB optimale
Stocker les données sur un volume séparé
Il est toujours idéal de séparer les données de votre base de données sur un volume séparé. Ce volume est spécifiquement destiné aux types de volumes de stockage rapides tels que les cartes SSD, NVMe ou PCIe. Par exemple, si l'ensemble de votre volume système tombe en panne, votre volume de base de données sera en sécurité et vous serez assuré de ne pas être affecté en cas de panne de votre matériel de stockage.
Optimiser MariaDB pour utiliser efficacement la mémoire
innodb_buffer_pool_size
La valeur principale à ajuster sur un serveur de base de données avec entièrement/principalement des tables XtraDB/InnoDB, peut être définie jusqu'à 80 % de la mémoire totale dans ces environnements. S'il est défini sur 2 Go ou plus, vous souhaiterez probablement également ajuster innodb_buffer_pool_instances. Vous pouvez définir cela dynamiquement si vous utilisez la version MariaDB>=10.2.2. Sinon, cela nécessite un redémarrage du serveur.
tmp_memory_table_size/max_heap_table_size
Pour tmp_memory_table_size (tmp_table_size), si vous avez affaire à des tables temporaires volumineuses, un réglage plus élevé offre des gains de performances car il sera stocké dans la mémoire. Ceci est courant sur les requêtes qui utilisent fortement GROUP BY, UNION ou des sous-requêtes. Bien que si max_heap_table_size est plus petit, la limite inférieure s'appliquera. Si une table dépasse la limite, MariaDB la convertit en une table MyISAM ou Aria. Vous pouvez voir s'il est nécessaire d'augmenter en comparant les variables d'état Created_tmp_disk_tables et Created_tmp_tables pour voir combien de tables temporaires sur le total créé devaient être converties sur disque. Souvent, les requêtes GROUP BY complexes sont responsables du dépassement de la limite.
Bien que max_heap_table_size, il s'agit de la taille maximale des tables MEMORY créées par l'utilisateur. La valeur définie sur cette variable n'est applicable que pour les tables nouvellement créées ou recréées et non pour celles existantes. Le plus petit de max_heap_table_size et tmp_table_size limite également les tables internes en mémoire. Lorsque la taille maximale est atteinte, toute autre tentative d'insertion de données recevra une erreur "table ... is full". Les tables temporaires créées avec CREATE TEMPORARY ne seront pas converties en Aria, comme cela se produit avec les tables temporaires internes, mais recevront également une erreur de table pleine.
innodb_log_file_size
Les grandes mémoires avec un traitement à grande vitesse et un disque d'E/S rapide ne sont pas nouvelles et ont un prix raisonnable comme il le recommande. Si vous préférez plus de gains de performances, en particulier lors de la gestion de vos transactions InnoDB, il est raisonnable de définir la variable innodb_log_file_size sur une valeur plus élevée, telle que 5 Gib ou même 10 Gio. Augmenter signifie que les transactions plus importantes peuvent s'exécuter sans avoir à effectuer d'E/S disque avant de valider.
join_buffer_size
Dans certains cas, vos requêtes ont tendance à ne pas utiliser une indexation appropriée ou simplement, il y a des instances pour lesquelles vous avez besoin de cette requête. À moins qu'elle ne soit fortement appelée ou invoquée du point de vue du client, la définition de cette variable est préférable au niveau de la session. Augmentez-le pour obtenir des jointures complètes plus rapides lorsque l'ajout d'index n'est pas possible, mais soyez conscient des problèmes de mémoire, car les jointures alloueront toujours la taille minimale.
Définir votre max_allowed_packet
MariaDB a la même nature que MySQL lors de la gestion des paquets. Il divise les données en paquets et le client doit connaître la valeur de la variable max_allowed_packet. Le serveur disposera d'un tampon pour stocker le corps avec une taille maximale correspondant à cette valeur max_allowed_packet. Si le client envoie plus de données que la taille max_allowed_packet, le socket sera fermé. La directive max_allowed_packet définit la taille maximale des paquets pouvant être envoyés.
La définition de cette valeur trop basse peut entraîner l'arrêt et la fermeture de la connexion client d'une requête, ce qui est assez courant pour recevoir des erreurs telles que ER_NET_PACKET_TOO_LARGE ou Connexion perdue au serveur MySQL pendant la requête. Idéalement, en particulier sur la plupart des demandes d'application aujourd'hui, vous pouvez commencer à le régler sur 512 Mo. S'il s'agit d'un type d'application à faible demande, utilisez simplement la valeur par défaut et définissez cette variable uniquement via la session si nécessaire si les données à envoyer ou à recevoir sont trop volumineuses par rapport à la valeur par défaut (16 Mo depuis MariaDB 10.2.4). Dans certaines charges de travail qui exigent le traitement de gros paquets, vous devez alors ajuster son plus haut en fonction de vos besoins, en particulier lors de la réplication. Si max_allowed_packet est trop petit sur l'esclave, cela provoque également l'arrêt du thread d'E/S par l'esclave.
Utiliser le pool de threads
Dans certains cas, ce réglage peut ne pas être nécessaire ou recommandé pour vous. Les pools de threads sont plus efficaces dans les situations où les requêtes sont relativement courtes et la charge est liée au processeur (charges de travail OLTP). Si la charge de travail n'est pas liée au processeur, vous pouvez toujours limiter le nombre de threads pour économiser de la mémoire pour les tampons de mémoire de la base de données.
L'utilisation de threadpool est une solution idéale, en particulier si votre système connaît un changement de contexte et que vous trouvez des moyens de réduire cela et de maintenir un nombre de threads inférieur au nombre de clients. Cependant, ce nombre ne doit pas non plus être trop bas, car nous voulons également utiliser au maximum les processeurs disponibles. Par conséquent, il devrait y avoir, idéalement, un seul thread actif pour chaque CPU sur la machine.
Vous pouvez définir les thread_pool_max_threads, thread_pool_min_threads pour le nombre maximum et minimum de threads. Contrairement à MySQL, ceci n'est présent que dans MariaDB.
Définissez la variable thread_handling qui détermine comment le serveur gère les threads pour les connexions client. En plus des threads pour les connexions client, cela s'applique également à certains threads internes du serveur, tels que les threads esclaves Galera.
Ajustez votre cache de table + max_connections
Si vous rencontrez des occurrences occasionnelles dans la liste des processus concernant les statuts d'ouverture de tables et de fermeture de tables, cela peut signifier que vous devez augmenter votre cache de table. Vous pouvez également surveiller cela via l'invite du client mysql en exécutant SHOW GLOBAL STATUS LIKE 'Open%table%' ; et surveiller les variables d'état.
Pour max_connections, si votre application nécessite de nombreuses connexions simultanées, vous pouvez commencer à définir ce paramètre sur 500.
Pour table_open_cache, il s'agira du nombre total de vos tables, mais il est préférable d'en ajouter davantage en fonction du type de requêtes que vous servez, car les tables temporaires doivent également être mises en cache. Par exemple, si vous avez 500 tables, il serait raisonnable de commencer par 1 500.
Pendant que votre table_open_cache_instances, commencez à le définir sur 8. Cela peut améliorer l'évolutivité en réduisant les conflits entre les sessions, le cache des tables ouvertes peut être partitionné en plusieurs instances de cache plus petites de taille table_open_cache / table_open_cache_instances.
Pour InnoDB, table_definition_cache agit comme une limite souple pour le nombre d'instances de table ouvertes dans le cache du dictionnaire de données InnoDB. La valeur à définir définira le nombre de définitions de table pouvant être stockées dans le cache de définitions. Si vous utilisez un grand nombre de tables, vous pouvez créer un grand cache de définition de table pour accélérer l'ouverture des 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. La valeur minimale est 400. La valeur par défaut est basée sur la formule suivante, plafonnée à une limite de 2 000 :
MIN(400 + table_open_cache / 2, 2000)Si le nombre d'instances de table ouvertes dépasse le paramètre table_definition_cache, le mécanisme LRU commence à marquer les instances de table pour éviction et les supprime finalement du cache du dictionnaire de données. 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. Le nombre d'instances de table avec des métadonnées mises en cache peut être supérieur à la limite définie par table_definition_cache, car les instances de table parent et enfant avec des relations de clé étrangère ne sont pas placées sur la liste LRU et ne sont pas susceptibles d'être évincées de la mémoire.
Contrairement à table_open_cache, table_definition_cache n'utilise pas de descripteurs de fichiers et est beaucoup plus petit.
Traitement du cache de requêtes
De préférence, nous vous recommandons de désactiver le cache des requêtes dans toute votre configuration MariaDB. Vous devez vous assurer que query_cache_type=OFF et query_cache_size=0 pour terminer la désactivation du cache de requête. Contrairement à MySQL, MariaDB prend toujours entièrement en charge le cache de requêtes et ne prévoit pas de retirer son support pour utiliser le cache de requêtes. Certaines personnes affirment que le cache de requêtes leur offre toujours des avantages en termes de performances. Cependant, cet article de Percona Le cache de requête MySQL :le pire ennemi ou le meilleur ami révèle que le cache de requête, s'il est activé, entraîne une surcharge et montre que les performances du serveur sont médiocres.
Si vous avez l'intention d'utiliser le cache de requêtes, assurez-vous de surveiller votre cache de requêtes en exécutant SHOW GLOBAL STATUS LIKE 'Qcache%';. Qcache_inserts contient le nombre de requêtes ajoutées au cache de requêtes, Qcache_hits contient le nombre de requêtes qui ont utilisé le cache de requêtes, tandis que Qcache_lowmem_prunes contient le nombre de requêtes qui ont été supprimées du cache en raison d'un manque de mémoire. En temps voulu, l'utilisation et l'activation du cache de requêtes peuvent devenir fragmentées. Un Qcache_free_blocks élevé par rapport à Qcache_total_blocks peut indiquer une fragmentation. Pour le défragmenter, exécutez FLUSH QUERY CACHE. Cela défragmentera le cache des requêtes sans supprimer aucune requête.
Surveillez toujours vos serveurs
Il est très important que vous surveilliez correctement vos nœuds MariaDB. Des outils de surveillance courants (comme Nagios, Zabbix ou PMM) sont disponibles si vous avez tendance à préférer les outils gratuits et open source. Pour les outils d'entreprise et complets, nous vous suggérons d'essayer ClusterControl, car il ne fournit pas seulement une surveillance, mais il offre également des conseillers de performance, des alertes et des alarmes qui vous aident à améliorer les performances de votre système et à rester à jour avec le courant. tendances au fur et à mesure que vous interagissez avec l'équipe d'assistance. La surveillance de la base de données avec ClusterControl est gratuite et fait partie de l'édition communautaire.
Conclusion
Le réglage de votre configuration MariaDB est presque la même approche que MySQL, mais avec quelques disparités, car il diffère dans certaines de ses approches et versions qu'il prend en charge. MariaDB est maintenant une entité différente dans le monde des bases de données et a rapidement gagné la confiance de la communauté sans aucun FUD. Ils ont leurs propres raisons pour lesquelles cela doit être implémenté de cette façon, il est donc très important que nous sachions comment régler cela et optimiser votre ou vos serveurs MariaDB.
