Ustawienia MySQL InnoDB page_cleaner mogą nie być optymalne

17

Widząc tę ​​notatkę w 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.)

Wydaje się, że tutaj jest coś takiego: instancja MySQL blokuje się „robi indeks SYNC”

Moje pytanie brzmi: jakie działania należy podjąć, jeśli w ogóle, gdy ta notatka jest widoczna w dziennikach?

Wersje MySQL i OS:
mysql-community- server- 5.7.9
-1.el7.x86_64 centos-release-7-1.1503.el7.centos.2.8.x86_64

Uruchamianie SHOW VARIABLES LIKE 'innodb%'; jak sugeruje pokazuje:

innodb_page_cleaners | 1
mysql innodb optimization logs configuration mcmacerson
źródło

Odpowiedzi:

11

Domyślna wartość innodb_page_cleaners została zmieniona z 1 na 4 w MySQL 5.7.8. Jeśli liczba wątków czyszczących strony przekracza liczbę instancji puli buforów, funkcja innodb_page_cleaners jest automatycznie ustawiana na tę samą wartość, co innodb_buffer_pool_instances

Sprawdź innodb_buffer_pool_instances przy pomocy:

mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_instances'

Możesz ustawić tylko innodb_page_cleanerstak wysoko, jak innodb_buffer_pool_instances. Jeśli chcesz innodb_page_cleaners=4, potrzebujesz również innodb_buffer_pool_instances=4.

Leandro
źródło
2
cóż, mam zarówno innodb_buffer_pool_instances, jak i innodb_page_cleaners ustawione na 8 i od czasu do czasu widzę ostrzeżenie. To tylko garstka pasiastych wirujących dysków klasy stacjonarnej podczas ciężkich operacji we / wy, takich jak optymalizacja stołu i podobne, domyślam się, że subtelny sposób mysql mówi ci, że twoje dyski są zbyt wolne;)
Aleksandar Ivanisevic
5

Ten sam problem występował u różnych klientów i okazało się, że problem był spowodowany ustawieniem wartości innodb_lru_scan_depth z wartości domyślnej 1024 na tak niską jak 128. Chociaż obniżenie tej wartości skraca czas przetwarzania transakcji, szczególnie w przypadku obciążeń związanych z zapisem Uważam, że ustawienie zbyt niskiej wartości spowodowałoby, że pula buforów nie byłaby w stanie nadążać za czyszczeniem niektórych swoich buforów i brudnych stron puli buforów.

W naszym przypadku zaobserwowaliśmy drastyczną poprawę poprzez zwiększenie wartości ze 128 do 256, ale ogólnie właściwa wartość zależy od sprzętu i rodzaju obciążenia. Sztuczka polega na znalezieniu właściwej wartości między zwiększeniem wydajności OLTP a pozwoleniem MySQL na utrzymanie puli buforów w czystości, aby strona_cleaner nie musiała wykonywać dużo pracy, jak stwierdzono w powyższym komunikacie ( „InnoDB: page_cleaner: 1000ms zamierzona pętla zajęło 15888 ms ” ).

Wartość można zmieniać dynamicznie bez ponownego uruchamiania MySQL, np

SET GLOBAL innodb_lru_scan_depth=256;
Brian Fenech
źródło
1
Jeśli zrestartuję MySQL, innodb_lru_scan_depth powraca do 1024, więc jak na stałe go zmienić?
Karim Samir
@KarimSamir Dodaj innodb_lru_scan_depth = 256gdzieś na my.cnfścieżce ładowania.
Quentin Skousen
0

Ten wątek StackOverflow może być przydatny ...

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

Zasadniczo oznacza to, że twoja baza danych otrzymuje zbyt wiele zapisów, co powoduje, że bufor buforowy wypełnia się brudnymi wartościami. To powoduje, że PageCleaner działa i usuwa brudne strony. Ponieważ było zbyt wiele brudnych stron niż zwykle, wyczyszczenie bufora zajęło więcej czasu PageCleaner .

innodb_lru_scan_depthkonkretna zmienna kontroluje, ile skanowania puli buforów należy wykonać w celu wyczyszczenia. Może to być duża wartość lub szybkość zapisu w systemie jest naprawdę wysoka, co powoduje dużą liczbę brudnych stron.

swayamraina
źródło