Caractéristiques du serveur

• RAM système totale: 8 Go (exécutant MySQL + autre chose que MySQL dessus, c'est-à-dire non dédié à MySQL)
• Nombre de cœurs CPU: 6
• J'ai des données dans la base de données s'élevant à environ 2 Go
• J'ai une taille de pool de mémoire tampon InnoDB définie sur 4 Go

Ce qui est mieux:

• Innodb Buffer Pool Instances défini sur 1?
• Instances de pool de mémoire tampon Innodb définies sur 2 (2 Go chacune)?
• Instances de pool de mémoire tampon Innodb définies sur 4 (1 Go chacune)?
• Instances de pool de mémoire tampon Innodb définies sur 8 (paramètre par défaut)

Je ne suis donc pas sûr de savoir comment raisonner en ce qui concerne les instances de pool de tampons et également l'ensemble "utiliser des instances ou subir un échange de système d'exploitation lorsque la taille du pool de tampons InnoDB est si grande".

Quand je reviens à MySQL 5.5, je penserais à la même chose.

Ce que j'ai appris au cours de ces années était le suivant: si le pool de tampons était supérieur à la moitié de la RAM installée et que innodb_buffer_pool_instances était de 1 (par défaut pour 5.5), la menace de permutation était toujours imminente.

J'en ai déjà parlé: existe-t-il une règle générale concernant la taille et le nombre d'instances d'un pool de mémoire tampon? . Dans ce post, j'ai mentionné un exemple d'un client qui avait 192 Go de RAM sur le serveur avec 162 Go de mémoire tampon. Lorsque innodb_buffer_pool_instances était égal à 1, l'échange s'est produit. Lorsque j'ai défini innodb_buffer_pool_instances à 2, les choses se sont améliorées.

Dans votre cas, étant donné que le pool de tampons est exactement la moitié, une valeur de 1 peut être OK. Je ne le risquerais pas. Je le mettrais à 2.

Puisque MySQL 5.6 a une valeur par défaut de 8, vous ne devriez plus avoir à y penser.

Je dirai ceci: la réponse d'Akuzminsky a le principe le plus élevé . Ma réponse est juste de tirer de la hanche sur la base des expériences passées (bonnes et mauvaises).

Le nombre d'instances de pool de mémoire tampon doit être augmenté pour éviter les conflits de mutex de pool de mémoire tampon.

Avec une taille de pool de mémoire tampon de 8 Go, je doute que vous verrez jamais la contention du mutex du pool de mémoire tampon.

MISE À JOUR 0 :

Je mentionne un pool de mémoire tampon de 8 Go dans la réponse tandis que dans la question d'origine, la mémoire totale était de 8 Go. Bien sûr, le pool de mémoire tampon doit être inférieur à 8 Go. 4 Go semblent être un bon début, mais assurez-vous qu'aucun échange ne se produit.

MISE À JOUR 1 :

// à partir des diapositives de Yasufumi (dans les versions récentes de MySQL, la sortie peut légèrement différer)

Pour déterminer s'il existe un conflit sur le pool de tampons, mutex collecte une douzaine d' SHOW ENGINE INNODB STATUSéchantillons pendant le temps de pointe.

Ensuite, agrégez-le à l'aide d'un extrait de shell:

#!/bin/sh
cat $1.innodb | grep "Mutex at " | cut -d"," -f1 | sort | uniq -c > /tmp/tmp1.txt 
cat $1.innodb | grep "lock on " | cut -d"-"
-f2- | sort | uniq -c > /tmp/tmp2.txt
cat /tmp/tmp1.txt /tmp/tmp2.txt | sort -n > $1.contention rm /tmp/tmp1.txt /tmp/tmp2.txt

ce qui donne une sortie comme celle-ci:

.....
4 lock on RW-latch at 0x7fb86b2c9138 created in file dict/dict0dict.c line 1356
6 lock on RW-latch at 0x7fb86b2c4138 created in file dict/dict0dict.c line 1356
12 lock on RW-latch at 0x7fb86b2d9538 created in file dict/dict0dict.c line 1356
20 lock on RW-latch at 0x7fb86b2db138 created in file dict/dict0dict.c line 1356
22 Mutex at 0x7fb86b28f0e0 created file btr/btr0sea.c line 139
30 lock on RW-latch at 0x7fb86b2ba938 created in file dict/dict0dict.c line 1356
36 lock on RW-latch at 0x7fb86b2bad38 created in file dict/dict0dict.c line 1356
71 Mutex at 0x7fb86b28ecb8 created file buf/buf0buf.c line 597
164 lock on RW-latch at 0x7fb86b28f0b8 created in file btr/btr0sea.c line 139

Si vous voyez un nombre élevé d'attente de mutex de pool de mémoire tampon, il est temps de considérer plusieurs instances de pool de mémoire tampon. Il est peu probable que la contention se produise sur un pool de tampons inférieur à ~ 48G.

Réglez "swappiness" sur 1 si votre système d'exploitation en dispose. Le problème peut être un MOO trop agressif.

Je suggère de définir cela pour correspondre au nombre maximum de threads MySQL que vous souhaitez exécuter simultanément. J'utilise le nombre de cœurs.

J'ai également défini innodb_read_io_threadset innodb_write_io_threadspour correspondre à ce nombre.

S'il innodb_buffer_pool_instancesest trop faible, vos threads risquent de se coincer dans les attentes de sémaphore. Cela fait que le CPU et les E / S semblent inactifs, même si le système doit être occupé - et la latence de votre application passera par le toit.