Zauważyłem to samo zjawisko w moich systemach. Zapytania, które zwykle trwają milisekundy, nagle zajmą 1-2 sekundy. Wszystkie moje przypadki są prostymi, jednotabelowymi instrukcjami INSERT/UPDATE/REPLACE --- nie na żadnych SELECTach. Nie widać żadnego obciążenia, blokowania ani narastania gwintu.
Podejrzewałem, że jest to spowodowane usuwaniem brudnych stron, opróżnianiem zmian na dysku lub jakimś ukrytym muteksem, ale muszę to zawęzić.
Również wykluczone
- Obciążenie serwera — brak korelacji z dużym obciążeniem
- Silnik – dzieje się z InnoDB/MyISAM/Memory
- Pamięć podręczna zapytań MySQL - dzieje się, czy jest włączona, czy wyłączona
- Rotacje dzienników — brak korelacji w zdarzeniach
Jedyna inna obserwacja, jaką mam w tym momencie, wynika z faktu, że uruchamiam tę samą bazę danych na wielu komputerach. Mam aplikację do intensywnego odczytu, więc używam środowiska z replikacją — większość obciążenia jest na urządzeniach podrzędnych. Zauważyłem, że chociaż obciążenie mastera jest minimalne, to tam zjawisko występuje częściej. Mimo że nie widzę problemów z blokowaniem, może to Innodb/Mysql ma problem ze współbieżnością (wątku)? Przypomnij sobie, że aktualizacje na urządzeniu podrzędnym będą jednowątkowe.
MySQL w wersji 5.1.48
Aktualizacja
Myślę, że mam trop do rozwiązania problemu w mojej sprawie. Na niektórych moich serwerach zauważyłem to zjawisko częściej niż na innych. Widząc, co różni się między różnymi serwerami i poprawiając różne rzeczy, zostałem doprowadzony do Zmienna systemowa MySQL innodb
innodb_flush_log_at_trx_commit .
Uważam, że dokument jest trochę niezręczny do przeczytania, ale innodb_flush_log_at_trx_commit może przyjmować wartości 1,2,0:
- Dla 1 bufor dziennika jest opróżniany do pliku dziennika dla każdego zatwierdzenia, a plik dziennika jest opróżniany na dysk dla każdego zatwierdzenia.
- Dla 2 bufor dziennika jest opróżniany do pliku dziennika dla każdego zatwierdzenia, a plik dziennika jest opróżniany na dysk co około 1-2 sekundy.
- Dla 0, bufor dziennika jest opróżniany do pliku dziennika co sekundę, a plik dziennika jest opróżniany na dysk co sekundę.
W rzeczywistości, w kolejności (1,2,0), jak zgłoszono i udokumentowano, powinieneś uzyskać wzrost wydajności w handlu, aby zwiększyć ryzyko.
Powiedziawszy to, stwierdziłem, że serwery z innodb_flush_log_at_trx_commit=0 działały gorzej (tj. miały 10-100 razy więcej „długich aktualizacji”) niż serwery z innodb_flush_log_at_trx_commit=2 . Co więcej, sytuacja natychmiast się poprawiła w złych instancjach, gdy zmieniłem ją na 2 (pamiętaj, że możesz to zmienić w locie).
Więc moje pytanie brzmi:na co jest ustawione twoje? Zauważ, że nie obwiniam tego parametru, ale raczej podkreślam, że jego kontekst jest związany z tym problemem.
