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

• Загальна системна оперативна пам’ять: 8 Гб (на ній працює MySQL + інші речі, крім MySQL, тобто не присвячені MySQL)
• Кількість ядер процесора: 6
• У мене є дані в db на суму близько 2 Гб
• У мене розмір буфера для InnoDB розміром 4 Гб

Що краще:

• Примірники буферного басейну Innodb встановлені на 1?
• Вимір басейну Innodb встановлений на 2 (2 ГБ у кожному)?
• Примірники буферного басейну Innodb встановлені на 4 (по 1 ГБ у кожному)?
• Примірники буферного басейну Innodb встановлені на 8 (налаштування за замовчуванням)

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

Коли я повернусь до MySQL 5.5, я б подумав про те саме.

Що я дізнався за ці роки, було наступне: Якщо буферний пул був більшим за половину встановленої оперативної пам’яті, а innodb_buffer_pool_instance був 1 (за замовчуванням для 5,5), загроза заміни завжди була неминучою.

Я обговорював це раніше: чи існує правило щодо розміру та кількості екземплярів буферного пулу? . У цій публікації я згадав приклад клієнта, який на сервері мав 192 ГБ оперативної пам’яті з буферним пулом 162 ГБ. Коли innodb_buffer_pool_in вещества було 1, відбувся замін . Коли я встановив innodb_buffer_pool_instance на 2, все стало краще.

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

Оскільки у MySQL 5.6 за замовчуванням 8, вам більше не слід думати про це.

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

Кількість екземплярів буферного пулу слід збільшити, щоб уникнути суперечок мутексу пулу буфера.

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

ОНОВЛЕННЯ 0 :

Я згадую 8Gb буферний пул у відповіді, тоді як в оригінальному питанні загальна пам'ять становила 8 Гб. Звичайно, буферний пул повинен бути менше 8 Гб. 4 Гб звучить як гарний старт, але переконайтесь, що не відбувається жодної заміни

ОНОВЛЕННЯ 1 :

// з слайдів Yasufumi (в останніх версіях 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, якщо ваша ОС має таке. Проблема може бути надмірно агресивним OOM.

Я б запропонував встановити це так, щоб відповідати максимальній кількості потоків MySQL, які ви хочете одночасно запустити. Я використовую кількість ядер.

Я також встановив innodb_read_io_threadsі innodb_write_io_threadsвідповідати цьому номеру.

Якщо innodb_buffer_pool_instancesвона занадто низька, ваші нитки, ймовірно, застрягнуть в очікуванні семафору. Це робить і процесор, і введення / виведення непрацюючими, навіть якщо система повинна бути зайнята - і затримка вашої програми пройде через дах.