Характеристики сервера

• Общий объем оперативной памяти: 8 ГБ (на нем работает MySQL + другие вещи, кроме MySQL, т.е. не выделенные для MySQL)
• Количество ядер процессора: 6
• У меня есть данные в БД размером около 2 ГБ
• У меня размер пула буферов InnoDB установлен на 4 ГБ

Как лучше:

• Экземпляры пула буферов Innodb установлены в 1?
• Экземпляры пула пула Innodb установлены в 2 (по 2 ГБ в каждом)?
• Экземпляры пула пула Innodb установлены в 4 (1 ГБ в каждом)?
• Экземпляры пула пула Innodb установлены на 8 (настройка по умолчанию)

Таким образом, я не уверен, как рассуждать, когда дело доходит до экземпляров пула буферов, а также всего «использования экземпляров или перенесения ОС при наличии такого большого размера пула буферов InnoDB».

Когда я вернусь к MySQL 5.5, я подумаю об этом.

За эти годы я узнал следующее: если буферный пул был больше, чем половина установленной оперативной памяти, а innodb_buffer_pool_instances был равен 1 (по умолчанию для 5.5), угроза подкачки всегда была неизбежна.

Я обсуждал это раньше: есть ли практическое правило относительно размера и количества экземпляров буферного пула? , В этом посте я упомянул пример клиента, который имел 192 ГБ ОЗУ на сервере с 162 ГБ буферного пула. Когда innodb_buffer_pool_instances был равен 1, произошла перестановка. Когда я установил innodb_buffer_pool_instances в 2, все стало намного лучше.

В вашем случае, поскольку буферный пул составляет ровно половину, значение 1 может быть в порядке. Я бы не упустил шанс. Я бы установил его на 2.

Поскольку в MySQL 5.6 по умолчанию установлено значение 8, вам не нужно больше об этом думать.

Скажу так: ответ акузминского имеет высший принцип . Мой ответ - стрельба из бедра, основанная на прошлом опыте (хорошем и плохом).

Количество экземпляров буферного пула должно быть увеличено, чтобы избежать конфликта мьютексов буферного пула.

С размером пула буферов 8 ГБ, я сомневаюсь, что вы когда-нибудь увидите конфликт мьютексов буферного пула.

ОБНОВЛЕНИЕ 0 :

В ответе я упомянул пул буферов 8 ГБ, тогда как в исходном вопросе общий объем памяти составил 8 ГБ. Конечно, буферный пул должен быть менее 8 ГБ. 4 Гб звучит как хорошее начало, но убедитесь, что обмен не произойдет.

ОБНОВЛЕНИЕ 1 :

// из слайдов Ясуфуми (в последних версиях MySQL вывод может немного отличаться)

Чтобы определить, есть ли конфликты в мьютексном пуле буферов, соберите дюжину SHOW ENGINE INNODB STATUSобразцов во время пика.

Затем объедините его, используя фрагмент оболочки:

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

который дает вывод, как это:

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

Если вы видите большое количество ожиданий мьютекса буферного пула, то пришло время рассмотреть несколько экземпляров буферного пула. Конфликт вряд ли произойдет с буферным пулом меньше, чем ~ 48G.

Установите «swappiness» на 1, если ваша ОС имеет такой. Проблема может быть в чрезмерно агрессивной ООМ.

Я бы предложил установить это так, чтобы оно соответствовало максимальному количеству потоков MySQL, которые вы хотите запустить одновременно. Я использую количество ядер.

Я тоже установил innodb_read_io_threadsи innodb_write_io_threadsсоответствовал этому номеру.

Если innodb_buffer_pool_instancesон слишком низкий, ваши потоки могут застрять в семафорных ожиданиях. Это делает процессор и ввод-вывод неактивными, хотя система должна быть занята - и задержка вашего приложения будет расти.