Проблемът е типичен за MySQL екземпляр, където имате висок процент на промени в базата данни. Като стартирате вашия импорт от 5 GB, вие създавате мръсни страници бързо. Тъй като се създават мръсни страници, нишката за почистване на страници е отговорна за копирането на мръсни страници от паметта на диска.
Във вашия случай предполагам, че не правите 5GB импортиране през цялото време. Така че това е изключително висока скорост на натоварване на данни и е временно. Вероятно можете да пренебрегнете предупрежденията, защото InnoDB постепенно ще навакса изоставането.
Ето подробно обяснение на вътрешните елементи, водещи до това предупреждение.
Веднъж в секунда, програмата за почистване на страници сканира буферния пул за мръсни страници, за да се промие от буферния пул на диск. Предупреждението, което видяхте, показва, че има много мръсни страници за изтриване и отнема повече от 4 секунди, за да се изтрие партида от тях на диск, когато трябва да завърши тази работа за по-малко от 1 секунда. С други думи, отхапва повече, отколкото може да сдъвче.
Вие коригирахте това, като намалихте innodb_lru_scan_depth от 1024 на 256. Това намалява колко далеч в буферния пул нишката за почистване на страници търси мръсни страници по време на своя цикъл веднъж в секунда. Вие го молите да хапва по-малки.
Имайте предвид, че ако имате много екземпляри на буферен пул, това ще накара прочистването да свърши повече работа. Отхапва innodb_lru_scan_depth количество работа за всеки екземпляр на буферен пул. Така че може да сте причинили това затруднение по невнимание, като увеличите броя на буферните пулове, без да намалявате дълбочината на сканиране.
Документацията за innodb_lru_scan_depth казва "Настройка, по-малка от стандартната, обикновено е подходяща за повечето работни натоварвания." Изглежда, че са дали на тази опция стойност, която е твърде висока по подразбиране.
Можете да поставите ограничение на IOPS, използвано от фоновото прочистване, с innodb_io_capacity и innodb_io_capacity_max настроики. Първата опция е меко ограничение на входно/изходната пропускателна способност, която InnoDB ще поиска. Но тази граница е гъвкава; ако зачервяването изостава от скоростта на създаване на нова мръсна страница, InnoDB динамично ще увеличи скоростта на зачервяване над тази граница. Втората опция дефинира по-строго ограничение за това колко далеч InnoDB може да увеличи скоростта на промиване.
Ако скоростта на зачервяване може да се справи със средната скорост на създаване на нови мръсни страници, тогава ще се оправите. Но ако постоянно създавате мръсни страници по-бързо, отколкото могат да бъдат прочистени, в крайна сметка вашият буферен пул ще се запълни с мръсни страници, докато мръсните страници надвиши innodb_max_dirty_page_pct на буферния пул. В този момент скоростта на промиване автоматично ще се увеличи и може отново да накара page_cleaner да изпраща предупреждения.
Друго решение би било да поставите MySQL на сървър с по-бързи дискове. Имате нужда от I/O система, която може да се справи с пропускателната способност, изисквана от изтриването на вашата страница.
Ако виждате това предупреждение през цялото време при среден трафик, може да се опитвате да правите твърде много заявки за писане на този MySQL сървър. Може да е време за мащабиране и разделяне на записите върху множество MySQL екземпляри, всеки със собствена дискова система.
Прочетете повече за инструмента за почистване на страници:
- Представяме нишка на page_cleaner в InnoDB (архивирано копие)
- MySQL-5.7 подобрява натоварванията, ориентирани към DML
