Налаштування MySQL InnoDB page_cleaner можуть бути не оптимальними

17

Побачивши цю замітку в mysqld.log:

[Note] InnoDB: page_cleaner: 1000ms intended loop took 15888ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.)

Тут, мабуть, згадується щось подібне: екземпляр MySQL зупиняє "робити індекс SYNC"

Моє запитання: які дії потрібно вжити, якщо такі є, коли ця примітка буде помічена в журналах?

MySQL і OS версії:
MySQL-спільноти server- 5.7.9 -1.el7.x86_64
CentOS-реліз-7-1.1503.el7.centos.2.8.x86_64

Запуск SHOW VARIABLES LIKE 'innodb%'; як було запропоновано:

innodb_page_cleaners | 1

— mcmacerson
джерело

11

Значення за замовчуванням innodb_page_cleaners було змінено з 1 на 4 у MySQL 5.7.8. Якщо кількість потоків очищення сторінок перевищує кількість екземплярів пулу буфера, innodb_page_cleaners автоматично встановлюється на те саме значення, що і innodb_buffer_pool_instance

Перевірте innodb_buffer_pool_in вещества за допомогою:

mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_instances'

Ви можете встановити лише innodb_page_cleanersмаксимальну висоту innodb_buffer_pool_instances. Якщо ви хочете, innodb_page_cleaners=4то вам також потрібно innodb_buffer_pool_instances=4.

— Леандро
джерело

2

добре, що у мене є і innodb_buffer_pool_in вещества, і innodb_page_cleaners встановлено 8, і я час від часу бачу попередження. Це лише купа смугастих крутильних настільних дисків під час важких операцій вводу / виводу, таких як оптимізація таблиці та подібного, я думаю, її тонкий спосіб mysql повідомляє вам, що ваші диски занадто повільні;)

— Олександр Іванисевич

5

Ми зіткнулися з тією ж проблемою у різних клієнтів і з’ясували, що ця проблема пов’язана з встановленням значення innodb_lru_scan_depth від типового 1024 до мінімального, ніж 128. Хоча зниження значення скорочує час, необхідний для обробки транзакції, особливо при обмежених робочих навантаженнях. Я вважаю, що встановлення значення занадто низьке зробить пул буфера не в змозі продовжувати очищати деякі його буфери та брудні сторінки пулу.

У нашому випадку ми спостерігали кардинальне поліпшення за рахунок збільшення значення з 128 до 256, але, як правило, правильне значення залежить від обладнання та типу навантаження. Трюк полягає в тому, щоб знайти правильне значення між підвищенням продуктивності OLTP та дозволом MySQL підтримувати буферний пул чистим, щоб не мати сторінку_cleaner, що потребує великої роботи, як зазначено у вищезгаданому повідомленні ( "InnoDB: page_cleaner: 1000 мс призначений цикл" зайняв 15888 мс " ).

Значення можна змінити динамічно без перезавантаження MySQL, наприклад

SET GLOBAL innodb_lru_scan_depth=256;

— Брайан Фенех
джерело

1

Якщо я перезавантажую MySQL innodb_lru_scan_depth повертається до 1024, то як назавжди змінити його?

— Карім Самір

@KarimSamir Додайте innodb_lru_scan_depth = 256десь у свій my.cnfшлях завантаження.

— Квентін Скусен

0

Цей потік StackOverflow може бути корисним ...

/programming/41134785/how-to-solve-mysql-warning-innodb-page-cleaner-1000ms-intended-loop-took-xxx

Це в основному означає, що ваша БД отримує занадто багато записів, викликаючи BufferPool заповнюватися брудними значеннями. Це запускає PageCleaner діяти та очищати брудні сторінки. Оскільки було занадто багато брудних сторінок, ніж зазвичай, потрібно було більше часу, щоб PageCleaner очистив буфер.

innodb_lru_scan_depthконкретна змінна контролює, яку частину сканування буферного пулу слід виконати для очищення. Це може бути або великим значенням, або пропускна здатність системи дійсно висока, що призводить до великої кількості брудних сторінок.

— swayamraina
джерело