Dlaczego wątki MySQL często pokazują status „zwolnienia elementów”, gdy pamięć podręczna zapytań jest wyłączona?

Podczas uruchamiania SHOW PROCESSLISTczęsto występuje duża liczba wątków WSTAW / AKTUALIZACJA w stanie „uwalnianie elementów”.

Podręcznik MySQL sugeruje, że przynajmniej część przyczyny, dla której wątek jest w tym stanie, obejmuje pamięć podręczną zapytań - prawdopodobnie byłoby to unieważnianie zapytań buforowanych z powodu zmienionych danych.

Jednak my query_cache_sizeustawiono na 0, co powinno całkowicie wyłączyć pamięć podręczną zapytań.

Jakie byłyby inne powody, by mieć tyle wątków w tym stanie?

Odpowiednie tabele wykorzystują silnik pamięci InnoDB.

Sprawdź wartość innodb_thread_concurrency.

Dla mojego systemu zwiększenie wartości z 8 do 32, zgodnie z wytycznymi w dokumentacji MySql , spowodowało zauważalny spadek liczby wątków jednocześnie zgłaszających stan „zwolnienia elementów”. Ponadto zmniejszony średni czas zapytania spadł o rząd wielkości.

Chociaż miało to duży wpływ na ogólną wydajność serwera, nie była to srebrna kula „uwalniania przedmiotów”. Mój ekosystem sprzętowy prowadzi mnie do hipotezy, że ten stan występuje głównie w systemach z „wolnymi” dyskami (2 x 10 000 dysków RAID 1) i jest mniej powszechny w systemach z szybszą pamięcią (RAID 10 x 15 000 dysków). Dlatego sprawdzenie wydajności dysku może być również uzasadnione.

Powodzenia!

Również:

Warto zauważyć, że domyślna wartość innodb_thread_concurrency różni się diametralnie w zależności od używanego wydania 5.0-punktowego.

Wartość domyślna zmieniała się kilka razy: 8 przed MySQL 5.0.8, 20 (nieskończona) z 5.0.8 do 5.0.18, 0 (nieskończona) z 5.0.19 do 5.0.20 i 8 (skończona) z 5.0.21 na. - źródło

Oznacza to, że pozornie nieszkodliwe uaktualnienie z 5.0.20 do 5.0.21 zmieniło wartość domyślną z nieskończonego na 8 i przyniosło ze sobą konsekwencje dla wydajności.

Uwalnianie elementów to etap wykonywania zapytania, w którym tymczasowe struktury, bufory itp. Są zwalniane. Na tym etapie wykonywana jest część pamięci podręcznej zapytań, ale to nie jedyne, co się tam dzieje. Sugerowałbym użycie POKAŻ PROFILE, aby zobaczyć, jak długo trwa ten etap w stosunku do innych etapów, a jeśli czas zajmuje problem, rozwiązywanie problemów za pomocą narzędzi takich jak profiler biedaka i profil.

Zgłoszono błąd dotyczący tego problemu dotyczącego „zwalniania elementów” i pamięci podręcznej zapytań . Chociaż błąd jest zamknięty, nie było wzmianki o innodb_thread_concurrency .

Przypadkowo rozmawiałem z Ronaldem Bradfordem w Percona Live NYC w maju. Powiedziałem mu o sytuacji, w której poprawiłem innodb_thread_concurrency, ponieważ wiele puli buforów InnoDB w MySQL 5.5 wytworzyło mnóstwo blokowania wątków i podejrzewałem, że dane w pamięci podręcznej najprawdopodobniej rozprzestrzeniły się w wielu pulach buforów.

Powiedział mi wprost, że nigdy nie powinienem ustawiać wartości względem innodb_thread_concurrency. Niech zawsze będzie wartością domyślną, która wynosi teraz zero (0). W ten sposób pozwalasz pamięci InnoDB decydować o tym, ile innodb_concurrency_tickets ma generować samodzielnie. To właśnie robi nieskończona współbieżność.

„Uwalnianie przedmiotów” najprawdopodobniej występuje częściej, gdy nakładamy ograniczenia na innodb_thread_concurrency. To zawsze powinno wynosić zero (0). Zaryzykuję i podniosę innodb_concurrency_tickets i zobaczę, czy to pomoże, czy nie.

Mieliśmy problem z dokładnie tymi samymi objawami. Okazało się, że dysk z plikami dziennika InnoDB zapełnił się. Warto sprawdzić.

Kolejna wskazówka: może być innodb fsync (). Spróbuj ustawić

innodb_flush_log_at_trx_commit = 2

W my.cnf

Plik dziennika innodb jest następnie opróżniany na dysk co 1-2 sekundy, zamiast tego ob przy każdym zatwierdzeniu. Nieznaczna kara za integralność danych, wielki wzrost prędkości.