Problem jest typowy dla instancji MySQL, w której występuje duża liczba zmian w bazie danych. Uruchamiając import 5 GB, szybko tworzysz brudne strony. Gdy tworzone są brudne strony, wątek czyszczący strony jest odpowiedzialny za kopiowanie brudnych stron z pamięci na dysk.
W twoim przypadku zakładam, że nie importujesz 5 GB cały czas. Jest to więc wyjątkowo wysoki wskaźnik ładowania danych i jest to tymczasowe. Prawdopodobnie możesz zignorować ostrzeżenia, ponieważ InnoDB stopniowo nadrobi zaległości.
Oto szczegółowe wyjaśnienie elementów wewnętrznych prowadzących do tego ostrzeżenia.
Raz na sekundę narzędzie czyszczące strony skanuje pulę buforów w poszukiwaniu zabrudzonych stron do opróżnienia z puli buforów na dysk. Ostrzeżenie, które widziałeś, pokazuje, że ma wiele brudnych stron do opróżnienia, a opróżnienie ich partii na dysk zajmuje ponad 4 sekundy, podczas gdy powinno zakończyć tę pracę w mniej niż 1 sekundę. Innymi słowy, odgryza więcej, niż może przeżuć.
Dostosowałeś to, zmniejszając innodb_lru_scan_depth z 1024 do 256. Zmniejsza to, jak daleko w puli buforów wątek czyszczący strony szuka brudnych stron podczas cyklu raz na sekundę. Prosisz go o mniejsze kęsy.
Zauważ, że jeśli masz wiele instancji puli buforów, spowoduje to, że opróżnianie wykona więcej pracy. Odgryza innodb_lru_scan_depth ilość pracy dla każdej instancji puli buforów. Mogłeś więc przypadkowo spowodować to wąskie gardło, zwiększając liczbę pul buforów bez zmniejszania głębokości skanowania.
Dokumentacja innodb_lru_scan_depth mówi „Ustawienie mniejsze niż domyślne jest zazwyczaj odpowiednie dla większości obciążeń”. Wygląda na to, że nadali tej opcji wartość, która jest domyślnie zbyt wysoka.
Możesz ustawić limit na liczbę IOPS używanych przez opróżnianie w tle za pomocą innodb_io_capacity i innodb_io_capacity_max opcje. Pierwsza opcja to miękkie ograniczenie przepustowości we/wy, której zażąda InnoDB. Ale ten limit jest elastyczny; jeśli opróżnianie jest opóźnione w tempie tworzenia nowej brudnej strony, InnoDB dynamicznie zwiększy częstotliwość opróżniania poza ten limit. Druga opcja określa bardziej rygorystyczny limit tego, jak bardzo InnoDB może zwiększyć szybkość opróżniania.
Jeśli tempo opróżniania nadąża za średnim tempem tworzenia nowych brudnych stron, wszystko będzie w porządku. Ale jeśli konsekwentnie tworzysz brudne strony szybciej niż można je opróżnić, w końcu twoja pula buforów zapełni się brudnymi stronami, dopóki brudne strony nie przekroczą innodb_max_dirty_page_pct puli buforów. W tym momencie częstotliwość opróżniania automatycznie wzrośnie i może ponownie spowodować wysłanie przez page_cleaner ostrzeżeń.
Innym rozwiązaniem byłoby umieszczenie MySQL na serwerze z szybszymi dyskami. Potrzebujesz systemu we/wy, który poradzi sobie z przepustowością wymaganą przez opróżnianie stron.
Jeśli widzisz to ostrzeżenie przez cały czas przy średnim ruchu, być może próbujesz wykonać zbyt wiele zapytań zapisu na tym serwerze MySQL. Być może nadszedł czas na skalowanie i podział zapisów na wiele instancji MySQL, z których każda ma własny system dyskowy.
Przeczytaj więcej o narzędziu do czyszczenia stron:
- Przedstawiamy wątek page_cleaner w InnoDB (kopia archiwalna)
- MySQL-5.7 poprawia obciążenia zorientowane na DML
