it-swarm.com.de

Optimale Anzahl von MySQL InnoDB-Pufferpoolinstanzen

Servereigenschaften

  • Gesamtsystem-RAM: 8 GB (mit MySQL + anderen Dingen als MySQL, d. H. Nicht für MySQL reserviert)
  • Anzahl der CPU-Kerne: 6
  • Ich habe Daten in der Datenbank in Höhe von ca. 2 GB
  • Ich habe InnoDB Buffer Pool Size auf 4 GB eingestellt

Welches ist besser:

  • Innodb Buffer Pool Instances auf 1 gesetzt?
  • Innodb Buffer Pool Instances auf 2 gesetzt (jeweils 2 GB)?
  • Innodb Buffer Pool Instances auf 4 gesetzt (jeweils 1 GB)?
  • Innodb Buffer Pool Instances auf 8 gesetzt (Standardeinstellung)

Ich bin mir daher nicht sicher, wie ich argumentieren soll, wenn es um Pufferpoolinstanzen geht, und auch nicht, wie man "Instanzen verwendet oder OS-Swap erleidet, wenn man eine so große InnoDB-Pufferpoolgröße hat".

13
Adergaard

Wenn ich zu MySQL 5.5 zurückkehre, würde ich über dasselbe nachdenken.

In diesen Jahren habe ich Folgendes gelernt: Wenn der Pufferpool größer als die Hälfte der installierten war RAM und innodb_buffer_pool_instances war 1 (Standard für 5.5) stand die Gefahr des Austauschs immer unmittelbar bevor.

Ich habe dies bereits besprochen: Gibt es eine Faustregel bezüglich der Größe und Anzahl der Pufferpoolinstanzen? . In diesem Beitrag erwähnte ich ein Beispiel für einen Client mit 192 GB RAM auf dem Server mit 162 GB Pufferpool. Wann innodb_buffer_pool_instances war 1, tauschte passiert. Wenn ich innodb_buffer_pool_instances auf 2 setze, wird es viel besser.

In Ihrem Fall kann ein Wert von 1 in Ordnung sein, da der Pufferpool genau die Hälfte beträgt. Ich würde es nicht riskieren. Ich würde es auf 2 setzen.

Da MySQL 5.6 einen Standardwert von 8 hat, sollten Sie nicht mehr darüber nachdenken müssen.

Ich werde dies sagen: akuzminskys Antwort hat das höchste Prinzip . Meine Antwort ist nur aus der Hüfte zu schießen, basierend auf früheren Erfahrungen (gut und schlecht).

7
RolandoMySQLDBA

Die Anzahl der Pufferpoolinstanzen sollte erhöht werden, um Mutexkonflikte im Pufferpool zu vermeiden.

Bei einer Pufferpoolgröße von 8 GB bezweifle ich, dass Sie jemals den Mutex-Konflikt im Pufferpool sehen werden.

UPDATE 0 :

Ich erwähne 8 GB Pufferpool in der Antwort, während in der ursprünglichen Frage der Gesamtspeicher 8 GB betrug. Sicher, der Pufferpool muss weniger als 8 GB betragen. 4 GB klingen nach einem guten Start, aber stellen Sie sicher, dass kein Austausch stattfindet.

UPDATE 1 :

// von Yasufumis Folien (in neueren MySQL-Versionen kann die Ausgabe geringfügig abweichen)

Um festzustellen, ob ein Konflikt im Pufferpool-Mutex vorliegt, sammeln Sie ein Dutzend SHOW ENGINE INNODB STATUS Samples während der Spitzenzeit.

Aggregieren Sie es dann mit dem Shell-Snippet:

#!/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

was eine Ausgabe wie diese ergibt:

.....
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

Wenn Sie eine hohe Anzahl von Mutex-Wartezeiten im Pufferpool feststellen, ist es an der Zeit, mehrere Pufferpoolinstanzen in Betracht zu ziehen. Es ist unwahrscheinlich, dass der Konflikt in einem Pufferpool auftritt, der kleiner als ~ 48G ist.

6
akuzminsky

Setzen Sie "swappiness" auf 1, wenn Ihr Betriebssystem solche hat. Das Problem kann ein übermäßig aggressiver OOM sein.

2
Rick James

Ich würde vorschlagen, dies so einzustellen, dass es der maximalen Anzahl von MySQL-Threads entspricht, die Sie gleichzeitig ausführen möchten. Ich benutze die Anzahl der Kerne.

Ich setze auch innodb_read_io_threads und innodb_write_io_threads, um dieser Nummer zu entsprechen.

Wenn innodb_buffer_pool_instances ist zu niedrig, Ihre Threads bleiben wahrscheinlich in Semaphor-Wartezeiten stecken. Dies lässt sowohl die CPU als auch die E/A im Leerlauf erscheinen, obwohl das System ausgelastet sein sollte - und Ihre Anwendungslatenz geht über das Dach.

0
Mark