Настройки 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 и ОС:
mysql-community-server- 5.7.9 -1.el7.x86_64
centos-release-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_instances.

Проверьте innodb_buffer_pool_instances с помощью:

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.

— Leandro
источник

2

ну, у меня и innodb_buffer_pool_instances и innodb_page_cleaners установлены на 8, и я иногда вижу предупреждение. Это просто куча чередующихся дисков настольного класса во время тяжелых операций ввода-вывода, таких как оптимизация таблиц и т. П., Я полагаю, это просто хитрый способ mysql сообщить вам, что ваши диски слишком медленные;)

— Александар Иванисевич

5

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

В нашем случае мы наблюдали резкое улучшение, увеличив значение со 128 до 256, но в целом правильное значение зависит от оборудования и типа нагрузки. Хитрость заключается в том, чтобы найти правильное значение между повышением производительности OLTP и разрешением MySQL поддерживать буферный пул в чистоте, чтобы не вызывать page_cleaner для выполнения большой работы, как указано в приведенном выше сообщении ( "InnoDB: page_cleaner: 1000ms предназначенный цикл заняло 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
источник