S'il y a une chose que je peux dire à propos de MySQL, c'est qu'InnoDB, son moteur de stockage transactionnel (compatible ACID), est effectivement multithread. Cependant, il est aussi multithread que vous le configurez !!! Même immédiatement "prêt à l'emploi", InnoDB fonctionne parfaitement dans un environnement à processeur unique, compte tenu de ses paramètres par défaut. Pour tirer parti des fonctionnalités de multithreading InnoDB, vous devez vous rappeler d'activer de nombreuses options.
innodb_thread_concurrency définit la limite supérieure du nombre de threads simultanés pouvant être maintenus ouverts par InnoDB. Le nombre optimal à définir pour cela est (2 X Nombre de CPU) + Nombre de disques. UPDATE : Comme je l'ai appris personnellement de la conférence Percona NYC, vous devez définir cette valeur sur 0 afin de permettre à InnoDB Storage Engine de rechercher le meilleur nombre de threads pour l'environnement dans lequel il s'exécute.
innodb_concurrency_tickets définit le nombre de threads pouvant contourner la vérification de la concurrence en toute impunité. Une fois cette limite atteinte, la vérification de la concurrence des threads redevient la norme.
innodb_commit_concurrency définit le nombre de transactions simultanées pouvant être validées. Étant donné que la valeur par défaut est 0, le fait de ne pas définir cette option permet à un nombre quelconque de transactions d'être validées simultanément.
innodb_thread_sleep_delay définit le nombre de millisecondes pendant lequel un thread InnoDB peut être en veille avant de revenir à la file d'attente InnoDB. La valeur par défaut est 10000 (10 sec).
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.
innodb_replication_delay impose un délai de traitement sur un esclave si innodb_thread_concurrency est atteint.
innodb_read_ahead_threshold autorise les lectures linéaires du nombre défini d'étendues (64 pages [page = 16K]) avant de passer en lecture asynchrone.
Le temps m'échapperait si je nommais plus d'options. Vous pouvez en savoir plus sur la documentation de MySQL .
La plupart des gens ne sont pas au courant de ces fonctionnalités et sont très satisfaits d'InnoDB, qui vient d'effectuer des transactions conformes à l'ACID. Si vous modifiez l'une de ces options, vous le faites à vos risques et périls.
J'ai joué avec les instances de pool de mémoire tampon multiples MySQL 5.5 (162 Go dans 9 instances de pools de mémoire tampon) et j'ai tenté de partitionner automatiquement les données en mémoire de cette façon. Certains experts estiment que cela devrait vous permettre d’améliorer les performances de 50%. Ce que j'ai obtenu est une tonne de blocage du fil qui a réellement fait ramper InnoDB. Je suis passé à 1 tampon (162 Go) et tout allait bien dans le monde. Je suppose que vous avez besoin d’experts Percona à votre disposition pour régler ce problème. Je serai à la conférence MySQL Percona à New York demain et poserai des questions à ce sujet si l'occasion se présente.
En conclusion, InnoDB se comporte bien maintenant dans un serveur multi-processeurs étant donné ses paramètres par défaut pour les opérations multithread. Les peaufiner demande beaucoup de soin, beaucoup de patience, une bonne documentation et un excellent café (ou Red Bull, Jolt, etc.).
Bonjour, bonsoir et bonne nuit !!!
MISE À JOUR 2011-05-27 20:11
Nous sommes revenus de la conférence MySQL Percona à New York jeudi. Quelle conférence. J'ai beaucoup appris, mais j'ai obtenu une réponse sur InnoDB. Ronald Bradford m'a informé que le réglage de innodb_thread_concurrency à 0 laisserait InnoDB choisir le meilleur plan d'action en interne avec la simultanéité des threads. Je vais expérimenter cela davantage dans MySQL 5.5.
MISE À JOUR 2011-06-01 11:20
En ce qui concerne une longue requête, InnoDB est conforme à ACID et fonctionne très bien avec le contrôle de simultanéité MultiVersion . Les transactions doivent pouvoir supporter des niveaux d'isolation (lectures répétables par défaut) qui empêchent les autres d'accéder aux données.
En ce qui concerne les systèmes multicœurs, InnoDB a parcouru un long chemin. Dans le passé, InnoDB ne pouvait pas fonctionner correctement dans un environnement multicœur. Je me souviens d'avoir dû exécuter plusieurs instances de mysql sur un seul serveur pour que les multiples cœurs distribuent les multiples processus mysqld sur les processeurs. Ce n'est plus nécessaire, grâce à Percona et plus tard à MySQL (Oracle, ce qui me fait encore peur), car ils ont développé InnoDB en un moteur de stockage plus mature qui peut accéder aux cœurs avec une simplicité sans trop de réglage. L'instance actuelle d'InnoDB peut aujourd'hui fonctionner correctement sur un serveur principal unique.