web-dev-qa-db-fra.com

Nombre optimal d'instances de pool de mémoire tampon MySQL InnoDB

Caractéristiques du serveur

  • RAM totale du système: 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 la taille du 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 d'OS lorsque la taille du pool de tampons InnoDB est si grande".

mysqlinnodbbuffer-pool
13
Adergaard

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 quantité installée RAM et innodb_buffer_pool_instances était 1 (par défaut pour 5.5), la menace de swapping était toujours imminente.

J'en ai déjà discuté: 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 RAM sur le serveur avec 162 Go Buffer Pool. Quand innodb_buffer_pool_instances était égal à 1, l'échange s'est produit. Lorsque j'ai défini innodb_buffer_pool_instances à 2, les choses ont changé meilleur.

Dans votre cas, étant donné que le pool de tampons est exactement la moitié, une valeur de 1 peut être OK. Je ne le hasarderais 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).

7
RolandoMySQLDBA

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 :

// de 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 mémoire tampon, mutex collecte une douzaine de SHOW ENGINE INNODB STATUS échantillons pendant les heures de pointe.

Puis agrégez-le à l'aide de l'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.

6
akuzminsky

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

2
Rick James

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_threads et innodb_write_io_threads pour correspondre à ce nombre.

Si innodb_buffer_pool_instances est 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.

0
Mark