Multi cœurs et performances MySQL

L’importance de la RAM est un fait établi, mais on dispose de beaucoup moins de données sur l’importance des cœurs et du multithreading en matière d’utilisation du processeur par MySQL. Je parle de la différence de courir MySQL sur 4cores vs 6cores vs 8cores et ainsi de suite.

Est-ce que différents moteurs de stockage utilisent le processeur différemment?

En ce qui concerne MySQL, il n’existe aucune comparaison entre les moteurs de stockage, à part le fait qu’il entre dans deux catégories de base:

• Transactionnel ( conforme à ACID )
• Non transactionnel

MySQL utilise plusieurs moteurs de stockage

• InnoDB (valeur par défaut à partir de MySQL 5.5)
• MyISAM (par défaut avant MySQL 5.5)
• ARCHIVER
• TROU NOIR
• CSV
• MÉMOIRE
• MRG_MYISAM
• FEDERATED
• NDB aka MySQL Cluster

En ce qui concerne les moteurs de stockage répertoriés, InnoDB et NDB sont les seuls à être compatibles ACID. Pourquoi est-ce important de le mentionner? Deux raisons:

• Les autres moteurs de stockage ne bénéficient tout simplement pas de la présence de plus de cœurs, mis à part les E / S de disque de base, l'utilisation du processeur et le débit global.
• Le code de chaque moteur de stockage non transactionnel, qui régit 14 opérations internes, quel que soit le moteur de stockage, n'a pas été conçu pour tirer parti de l'accès à plusieurs cœurs.

InnoDB sous MySQL 5.5, InnoDB Plugin), et la XtraDB de Percona Server disposent d’options que vous pouvez définir pour pouvoir accéder à plusieurs cœurs (Percona Server le fait depuis plus longtemps). En fait, Percona injecte environ 30 000 lignes de code dans le but d’améliorer les performances d’InnoDB à chaque nouvelle version GA du code source MySQL. Nous pouvons être sûrs qu'Oracle a intégré ses propres améliorations issues de leur propre groupe de réflexion à InnoDB pour les opérations multicœurs (depuis MySQL 5.1.38).

Avec la nécessité d'exécuter MVCC sur des données conjointement avec le verrouillage des lignes / pages, les performances des transactions peuvent désormais être instrumentées, mesurées et configurées.

S'il y a une chose que j'ai appris sur l'utilisation de plusieurs cœurs, c'est que vous devez optimiser InnoDB et ne pas simplement vous fier à InnoDB .

MISE À JOUR 2011-09-20 08:03 EDT

En ce qui concerne InnoDB, qui tire parti de tous les cœurs, nous devons rester vigilants. Les cœurs doivent également s'occuper d'autres problèmes (système d'exploitation, disque, mémoire, applications, surveillance, etc.) dans le serveur de base de données. Pour ceux qui ont des budgets modestes, beaucoup ont tendance à avoir un serveur de base de données qui fournit également NFS, la surveillance de Munin, le support d'applications pour JBoss, PHP, etc. Si vous voulez que MySQL, et plus particulièrement InnoDB, utilise plus de cœurs, le serveur de base de données doit être exclusivement dédié à MySQL et le système d'exploitation / disque / mémoire ne doit fonctionner que sur MySQL . Dans cette perspective, InnoDB impliquera plus de cœurs sans aucun doute .

Quant à InnoDB Plugin, il a été mentionné simplement pour montrer les initiatives précédentes visant à obtenir un meilleur InnoDB de la part de MySQL (hein, Oracle. Désolé, je ne tire pas encore la langue.) MySQL 5.1.38 indiquait de nouvelles variables pour appeler plus d’activité principale.

Par exemple, innodb_read_io_threads et innodb_write_io_threads (les deux depuis MySQL 5.1.38) allouent le nombre spécifié de threads pour les lectures et les écritures. La valeur par défaut est 4 et la valeur maximale est 64. Les paramètres par défaut et max étant si différents (4 - 64), InnoDB indique qu'AndoDB est aussi multithread et aussi intensif que vous le configurez !!!

Percona a pris en charge les besoins de la communauté MySQL pour accéder à davantage de cœurs avec InnoDB. En conséquence, MySQL a commencé à faire de même. Je dois admettre que Oracle (beurk) a apporté les améliorations nécessaires pour renforcer l'activité principale.

Je trouve que parler de moteurs de stockage utilisant des cœurs peut être trompeur pour les débutants. À condition qu'un programme soit suffisamment multithread, le système d'exploitation le planifie sur autant de cœurs que possible.

Le problème spécifique qui limite la mise à l'échelle de l'unité centrale est lorsque le code de verrouillage interne ( mutex ) a des conflits et empêche les threads de s'exécuter simultanément. Tous les moteurs de stockage nécessiteront des mutex, mais il y en a certainement des plus chauds dans MyISAM.

Si nous ignorons une seconde la controverse sur les mutex et revenons à votre question principale: à quel point est-il important d'avoir plusieurs cœurs? -

J'aime disposer de nombreux cœurs pour les charges de travail servant les demandes des utilisateurs. Avoir beaucoup peut réduire les écarts entre les temps de requête. Pensez-y comme si vous faisiez la queue au super marché avec 12 allées ouvertes contre seulement 2.

Mise à jour : j'ai écrit un article de blog sur pourquoi l'importance de l'évolutivité verticale (multi-cœurs) est importante.