Comment réglez-vous MySQL pour une lourde charge de travail InnoDB?

En supposant un système OLTP de production avec des tables à prédominance InnoDB

• Quels sont les symptômes communs d'un système mal configuré / mal configuré?
• Quels paramètres de configuration changez-vous le plus souvent par défaut?
• Comment repérez-vous les goulots d'étranglement potentiels avant qu'il y ait un problème?
• Comment reconnaissez-vous et résolvez-vous les problèmes actifs?

Toute anecdote détaillant des statusvariables spécifiques et des diagnostics serait appréciée.

Voici un bon article de Jenny Chen de Sun sur le réglage InnoDB. Elle écrit beaucoup de blogs sur MySQL. Certaines d'entre elles sont spécifiques à Solaris (par exemple, en utilisant DTrace ), mais l'ensemble du blog regorge de détails intéressants.

Fait intéressant, dans MySQL 5.5, vous pouvez maintenant avoir plusieurs pools de tampons 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, il est prévu d’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 de 64. J'ai décidé de configurer 144 Go. Je règle donc 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 mémoire tampon InnoDB. Il y avait trop de verrous et de conflits. Je suis passé à un seul pool de mémoire tampon de 162 Go + en définissant read_io_threads et write_io_threads sur 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 plus grand que le nombre total de processeurs physiques installés installés , vous incitez le système d'exploitation à permuter la mémoire à intervalles réguliers en raison d'un pool de mémoire tampon InnoDB complet. L'option de MySQL 5.5 appelée innodb_buffer_pool_instances peut être utilisée pour diviser le pool de mémoire tampon. Hier, j'ai correctement implémenté ceci pour le client que j'ai mentionné dans ma réponse l'an dernier. Il me reste 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 de base de données 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 immédiatement mis en pratique pour mon client. J'ai couru cette commande

numactl --hardware

J'ai vu un mappage de 192 Go de RAM du serveur en tant que 96 Go sur chaque cœur physique. Par conséquent, je règle innodb_buffer_pool_instances à 2. Les choses se présentent bien actuellement. Je mettrai à jour ma réponse pour voir comment cela affecte la permutation de mémoire pour les 2 prochains monts.

Vous voudrez peut-être explorer les ressources suivantes:

• Une FAQ des meilleures pratiques
• Manuel: réglage des paramètres du serveur
• Manuel: Réglage InnoDB
• Une liste plus ancienne de variables importantes.

Tout d'abord, augmentez la taille par défaut du pool de mémoire tampon InnoDB dans my.cnf (je crois que la taille par défaut est de 8 Mo)

Vous devriez probablement définir ceci à 75% de votre taille de RAM (en général)

Quels paramètres de configuration changez-vous le plus souvent par défaut?

configuration de la mémoire