Jak rozwiązać ostrzeżenie mysql: "InnoDB: page_cleaner: zamierzona pętla 1000ms zajęła XXX ms. Ustawienia mogą nie być optymalne"?

Question

Uruchomiłem mysql import mysql dummyctrad < dumpfile.sql na serwerze, a jego wzięcie trwa zbyt długo. Plik zrzutu jest około 5G. CentOS server 6 pamięci = procesory 16G i 8core, MySQL v 5.7 x64

Czy te normalne komunikaty/kawaler "czeka na stole flush" i wiadomość InnoDB: page_cleaner: 1000ms intended loop took 4013ms. The settings might not be optimal

zawartość dziennika mysql

2016-12-13T10:51:39.909382Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4013ms. The settings might not be optimal. (flushed=1438 and evicted=0, during the time.) 
2016-12-13T10:53:01.170388Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4055ms. The settings might not be optimal. (flushed=1412 and evicted=0, during the time.) 
2016-12-13T11:07:11.728812Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4008ms. The settings might not be optimal. (flushed=1414 and evicted=0, during the time.) 
2016-12-13T11:39:54.257618Z 3274915 [Note] Aborted connection 3274915 to db: 'dummyctrad' user: 'root' host: 'localhost' (Got an error writing communication packets) 

processlist \

mysql> show processlist \G; 
*************************** 1. row *************************** 
    Id: 3273081 
    User: root 
    Host: localhost 
    db: dummyctrad 
Command: Field List 
    Time: 7580 
    State: Waiting for table flush 
    Info: 
*************************** 2. row *************************** 
    Id: 3274915 
    User: root 
    Host: localhost 
    db: dummyctrad 
Command: Query 
    Time: 2 
    State: update 
    Info: INSERT INTO `radacct` VALUES (351318325,'kxid ge:7186','abcxyz5976c','user100 
*************************** 3. row *************************** 
    Id: 3291591 
    User: root 
    Host: localhost 
    db: NULL 
Command: Query 
    Time: 0 
    State: starting 
    Info: show processlist 
*************************** 4. row *************************** 
    Id: 3291657 
    User: remoteuser 
    Host: portal.example.com:32800 
    db: ctradius 
Command: Sleep 
    Time: 2 
    State: 
    Info: NULL 
4 rows in set (0.00 sec) 

Aktualizacja-1

mysqlforum, innodb_lru_scan_depth

zmieniając innodb_lru_scan_depth wartości 256 poprawiły czas wykonywania zapytań INSERT + Brak komunikat ostrzegawczy w dzienniku, domyślny był innodb_lru_scan_depth = 1024;

SET GLOBAL innodb_lru_scan_depth=256;

Answer 1

InnoDB: page_cleaner: 1000ms przeznaczone pętla wziął 4013ms. Ustawienia mogą nie być optymalne. (przepłukane = 1438 i eksmitowane = 0, w czasie).

Problem jest typowy dla instancji MySQL, w której występuje wysoki wskaźnik zmian w bazie danych. Po uruchomieniu importu 5 GB szybko tworzysz brudne strony. W miarę tworzenia brudnych stron wątek usuwania stron jest odpowiedzialny za kopiowanie brudnych stron z pamięci na dysk.

W twoim przypadku zakładam, że nie importujesz 5 GB przez cały czas. Jest to wyjątkowo wysoki wskaźnik obciążenia danych i jest tymczasowy. Prawdopodobnie można zignorować ostrzeżenia, ponieważ InnoDB stopniowo będzie nadrabiać zaległości.

---

Oto szczegółowe wyjaśnienie elementów wewnętrznych prowadzących do tego ostrzeżenia.

Raz na sekundę moduł czyszczący strony skanuje pulę buforów pod kątem brudnych stron, aby wypróżnić się z puli buforów na dysk. Ostrzeżenie, które zobaczyłeś, pokazuje, że ma dużo brudnych stron do spłukania, i zajmuje ponad 4 sekundy, aby opróżnić partię z nich na dysk, kiedy powinna zakończyć tę pracę w czasie poniżej 1 sekundy. Innymi słowy, gryzą więcej, niż potrafią żuć.

Dostosowałeś to, redukują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 ukąszenia.

Należy pamiętać, że jeśli masz wiele instancji puli buforów, spowoduje to spłukiwanie, aby wykonać więcej pracy. To bites off innodb_lru_scan_depth ilość pracy dla każdej instancji puli buforów. Być może nieumyślnie spowodowałeś to wąskie gardło, zwiększając liczbę pul buforów bez zmniejszania głębokości skanowania.

Dokumentacja dla innodb_lru_scan_depth mówi "Ustawienie mniejsze niż domyślne jest ogólnie 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 IOPS używanym przez płukanie tła, z opcjami innodb_io_capacity i innodb_io_capacity_max. Pierwsza opcja to miękkie ograniczenie przepustowości we/wy, o które poprosi InnoDB. Ale ten limit jest elastyczny; jeśli spłukiwanie spadnie poniżej poziomu tworzenia nowych brudnych stron, InnoDB będzie dynamicznie zwiększać szybkość spłukiwania powyżej tego limitu. Druga opcja określa bardziej restrykcyjne ograniczenie zakresu, w jakim InnoDB może zwiększyć szybkość płukania.

Jeśli tempo płukania może nadążyć za średnią szybkością tworzenia nowych brudnych stron, będzie w porządku. Ale jeśli konsekwentnie tworzysz brudne strony szybciej niż można je przepłukać, w końcu twoja pula buforów zapełni brudne strony, dopóki brudne strony nie przekroczą wartości innodb_max_dirty_page_pct puli buforów. W tym momencie wskaźnik zaczerwienienia automatycznie wzrośnie i może ponownie spowodować, że page_cleaner wyśle ​​ostrzeżenia.

Innym rozwiązaniem byłoby umieszczenie MySQL na serwerze z szybszymi dyskami. Potrzebny jest system I/O, który może obsłużyć przepustowość wymaganą przez spłukiwanie strony.

Jeśli zobaczysz to ostrzeżenie przez cały czas w średnim ruchu, możesz próbować wykonać zbyt wiele zapytań do zapisu na tym serwerze MySQL. Być może nadszedł czas na skalowanie i podzielenie zapisów na wiele instancji MySQL, każdy z własnym systemem dyskowym.

Czytaj więcej o czystsze Strona: https://blogs.oracle.com/mysqlinnodb/entry/introducing_page_cleaner_thread_in