Charakterystyka serwera

• Całkowita pamięć RAM systemu: 8 GB (na nim działa MySQL + inne rzeczy niż MySQL, tzn. Nie jest dedykowana MySQL)
• Liczba rdzeni procesora: 6
• Mam dane w bazie danych wynoszące około 2 GB
• Mam wielkość puli buforów InnoDB ustawioną na 4 GB

Co jest lepsze:

• Wystąpienia Innodb Buffer Pool Instances ustawione na 1?
• Wystąpienia Innodb Buffer Pool Instances ustawione na 2 (2 GB w każdym)?
• Wystąpienia Innodb Buffer Pool Instances ustawione na 4 (1 GB w każdym)?
• Instancje wystąpień puli buforów Innodb ustawione na 8 (ustawienie domyślne)

Nie jestem więc pewien, jak rozumować, jeśli chodzi o instancje puli buforów, a także całe „użycie instancji lub ucieczka systemu operacyjnego przy tak dużej wielkości puli buforów InnoDB”.

Kiedy wracam do MySQL 5.5, myślałem o tym samym.

Przez te lata nauczyłem się następujących rzeczy: jeśli pula buforów była większa niż połowa zainstalowanej pamięci RAM, a innodb_buffer_pool_instances wynosił 1 (domyślnie dla 5.5), zagrożenie zamianą zawsze było nieuchronne.

Omówiłem to wcześniej: Czy istnieje ogólna zasada dotycząca wielkości i liczby instancji puli buforów? . W tym poście wspomniałem o przykładzie klienta, który miał 192 GB pamięci RAM na serwerze z pulą buforów 162 GB. Kiedy innodb_buffer_pool_instances miał 1, nastąpiła zamiana. Kiedy ustawiłem innodb_buffer_pool_instances na 2, sytuacja się poprawiła.

W twoim przypadku, ponieważ pula buforów wynosi dokładnie połowę, wartość 1 może być OK. Nie zaryzykowałbym tego. Ustawiłbym na 2.

Ponieważ MySQL 5.6 ma domyślną wartość 8, nie powinieneś już o tym myśleć.

Powiem tak: odpowiedź akuzminsky'ego ma najwyższą zasadę . Moja odpowiedź to po prostu strzelanie z biodra w oparciu o wcześniejsze doświadczenia (dobre i złe).

Liczba instancji puli buforów powinna zostać zwiększona, aby uniknąć rywalizacji o muteks puli buforów.

W przypadku puli buforów o wielkości 8 GB wątpię, czy kiedykolwiek zobaczysz rywalizację o muteks puli buforów.

AKTUALIZACJA 0 :

Wspominam o puli buforów 8 Gb w odpowiedzi, podczas gdy w pierwotnym pytaniu całkowita pamięć wynosiła 8 GB. Jasne, pula buforów musi być mniejsza niż 8 GB. 4 GB to dobry początek, ale upewnij się, że nie nastąpi zamiana.

AKTUALIZACJA 1 :

// ze slajdów Yasufumi (w najnowszych wersjach MySQL dane wyjściowe mogą się nieznacznie różnić)

Aby ustalić, czy istnieje spór o muteks puli buforów, zbierz kilkanaście SHOW ENGINE INNODB STATUSpróbek w czasie szczytu.

Następnie agreguj go za pomocą fragmentu powłoki:

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

co daje takie wyjście:

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

Jeśli widzisz wysoką liczbę muteksów w puli buforów, czas rozważyć kilka instancji puli buforów. Rywalizacja raczej nie zdarzy się na puli buforów mniejszej niż ~ 48G.

Ustaw „swapiness” na 1, jeśli twój system operacyjny ma taką możliwość. Problemem może być zbyt agresywna OOM.

Sugerowałbym ustawienie tej wartości tak, aby była zgodna z maksymalną liczbą wątków MySQL, które chcesz uruchomić jednocześnie. Używam liczby rdzeni.

Ustawiłem także innodb_read_io_threadsi innodb_write_io_threadsdopasowałem ten numer.

Jeśli innodb_buffer_pool_instancesjest za niski, twoje wątki mogą utknąć w semaforze. To sprawia, że ​​zarówno procesor, jak i operacje we / wy wydają się być bezczynne, nawet jeśli system powinien być zajęty - a opóźnienie aplikacji przejdzie przez dach.