Comment régler MySQL pour une lourde charge de travail InnoDB?
En supposant une production OLTP système avec principalement des tables InnoDB
- Quels sont les symptômes courants d'un système mal réglé/mal configuré?
- Quels paramètres de configuration modifiez-vous le plus souvent par rapport à leurs valeurs par défaut?
- Comment repérez-vous les goulots d'étranglement potentiels avant qu'il n'y ait un problème?
- Comment reconnaissez-vous et résolvez-vous les problèmes actifs?
Toute anecdote détaillant des variables et des diagnostics status spécifiques serait appréciée.
Fait intéressant, dans MySQL 5.5, vous pouvez maintenant avoir plusieurs pools de mémoire tampon innodb.
Les paramètres qui vous intéressent sont
- innodb_buffer_pool_instances (la valeur par défaut est 1)
- innodb_buffer_pool_size (la valeur par défaut est 1G)
Dans environ un mois, je suis censé implémenter 112 pools de mémoire tampon innodb pour un client. Je vous ferai savoir comment ça s'est passé.
MISE À JOUR 2011-02-27 21:57 EDT
J'ai découvert que la valeur maximale pour innodb_buffer_pool_instances est 64. J'ai décidé de configurer 144 Go, j'ai donc défini innodb_buffer_pool_instances à 18 et innodb_buffer_pool_size à 8. Je charge actuellement le serveur avec 450 Go.
MISE À JOUR 2011-04-28 13:44 EDT
J'ai essayé plusieurs pools de tampons InnoDB. Il y avait trop de verrouillage de filetage et de conflit. Je suis passé à un seul pool de tampons de 162 Go + paramètre read_io_threads et write_io_threads à 64 (valeur maximale). Cela a fonctionné beaucoup mieux.
MISE À JOUR 2012-07-03 17:27 EDT
J'ai appris quelque chose d'incroyable sur MySQL. Si vous allouez un seul pool de mémoire tampon InnoDB monolithique qui est plus grand que Total installé divisé par le nombre de CPU physiques, votre incitera le système d'exploitation à échanger de la mémoire à intervalles réguliers en raison d'un pool de tampons InnoDB complet. L'option de MySQL 5.5 connue sous le nom de innodb_buffer_pool_instances peut être utilisée pour diviser le pool de tampons. Hier, j'ai correctement implémenté cela pour le client que j'ai mentionné dans ma réponse l'année dernière. J'ai encore 162 Go pour le pool de mémoire tampon du client. J'ai défini l'option innodb_buffer_pool_instances du serveur sur 2 car chaque serveur DB est à double hexacore. Je pensais le mettre à 12 mais un collègue m'a montré un blog de Jeremy Cole sur MySQL et Swappiness . Après l'avoir lu, je l'ai mis en pratique immédiatement pour mon client. J'ai exécuté cette commande
numactl --hardware
J'ai vu un mappage de 192 Go de serveur RAM en tant que 96 Go pour chaque cœur physique. Par conséquent, j'ai défini innodb_buffer_pool_instances à 2. Les choses vont bien en ce moment. Je mettrai à jour ma réponse pour voir comment cela affecte l'échange de mémoire pour les 2 prochains mois.
Vous voudrez peut-être explorer les ressources suivantes:
- A FAQ of meilleures pratiques
- Manuel: réglage des paramètres du serveur
- Manuel: réglage InnoDB
- Une ancienne liste de variables importantes.
Tout d'abord, augmentez la taille par défaut du pool de tampons InnoDB dans my.cnf (je pense que c'est par défaut à 8 Mo)
Vous devriez probablement définir cela à 75% de votre taille RAM (en général)