Servereigenschaften

• Gesamtsystem-RAM: 8 GB (mit MySQL + anderen Dingen als MySQL, dh nicht für MySQL)
• 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".

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 des installierten Arbeitsspeichers war und innodb_buffer_pool_instances 1 war (Standard für 5.5), stand die Gefahr eines 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 habe ich ein Beispiel für einen Client erwähnt, der 192 GB RAM auf dem Server mit 162 GB Pufferpool hatte. Wenn innodb_buffer_pool_instances 1 war, wurde getauscht. 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 das 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).

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 SHOW ENGINE INNODB STATUSwährend der Spitzenzeit ein Dutzend Proben.

Aggregieren Sie es dann mit einem 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 feststellen, dass die Anzahl der Mutex-Wartezeiten im Pufferpool hoch ist, müssen Sie mehrere Pufferpoolinstanzen berücksichtigen. Es ist unwahrscheinlich, dass der Konflikt in einem Pufferpool auftritt, der kleiner als ~ 48G ist.

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

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 habe auch diese Nummer eingestellt innodb_read_io_threadsund innodb_write_io_threadsangepasst.

Wenn innodb_buffer_pool_instanceses zu niedrig ist, bleiben Ihre Threads wahrscheinlich in Semaphor-Wartezeiten hängen. 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.