Ciekawy przypadek HADR_SYNC_COMMIT czeka

HADR_SYNC_COMMITW naszym otoczeniu zauważamy ciekawy wzór oczekiwania. Mamy trzy repliki; jedna podstawowa, jedna pomocnicza synchronizacja i jedna asynchroniczna pomocnicza w centrum danych, a my właśnie dodaliśmy trzy kolejne repliki ASYNC w innym centrum danych (w odległości około 2400 mil).

Od tego czasu zaczęliśmy zauważać ogromny wzrost HADR_SYNC_COMMIToczekiwań. Kiedy patrzymy na aktywne sesje, widzimy szereg COMMIT TRANSACTIONzapytań oczekujących na replikę SYNC

Na zrzucie ekranu wyraźnie widać, że nastąpił skok w HADR_SYNC_COMMIToczekiwaniu na 29 czerwca i ostatecznie upuściliśmy „dwie” trzy repliki asynchronicznej w zdalnym centrum danych 1 lipca w południe. To znacznie skróciło czas oczekiwania.

Co sprawdziliśmy do tej pory - kolejka wysyłania dziennika, kolejka Ponów, czas ostatniego zahartowania i czas ostatniego zatwierdzenia w zdalnych replikach. Mamy ciągłe serie małych transakcji w godzinach pracy, dlatego kolejki wysyłania są dość małe w danym znaczniku czasu (gdziekolwiek między 60 KB a 1 MB).
Zdalne repliki są prawie zsynchronizowane, różnica między czasem ostatniego zatwierdzenia a czasem ostatniego zahartowania jest bardzo mała dla każdego pojedynczego lsn w replikach.

Rura sieciowa ma rozmiar 10G i zmieniliśmy rozmiar bufora nadawczego z 256 megabajtów na 2 gigabajty, przy założeniu, że sieć upuszcza pakiety i przesyła je ponownie; tak czy inaczej, to niewiele pomogło.

Zastanawiam się więc, co repliki ASYNC mają wspólnego z HADR_SYNC_COMMIToczekiwaniem? Czy replika SYNC nie powinna polegać sama na tym typie oczekiwania, czego tu brakuje?

Najpierw opis zdarzenia oczekiwania, którego dotyczy Twoje pytanie, to:

Oczekiwanie na przetwarzanie zatwierdzania transakcji dla zsynchronizowanych pomocniczych baz danych w celu zahartowania dziennika. Oczekiwanie to jest również odzwierciedlane przez licznik wydajności opóźnienia transakcji. Ten typ oczekiwania jest oczekiwany dla zsynchronizowanych grup dostępności i wskazuje czas wysłania, zapisu i potwierdzenia dziennika do pomocniczych baz danych.

https://msdn.microsoft.com/en-us/library/ms179984.aspx

Zagłębiając się w mechanikę tego czekania, masz bloki dziennika przesyłane i hartowane, ale odzyskiwanie nie zostało ukończone na zdalnych serwerach. W takim przypadku i biorąc pod uwagę, że dodałeś dodatkowe repliki, jest oczywiste, że Twój HADR_SYNC_COMMIT może wzrosnąć z powodu wzrostu wymagań dotyczących przepustowości. W tym przypadku Aaron Bertrand ma dokładnie rację w swoich komentarzach do pytania.

Źródło: http://blogs.msdn.com/b/psssql/archive/2013/04/26/alwayson-hadron-learning-series-hadr-sync-commit-vs-writelog-wait.aspx

Zagłębiam się w drugą część pytania na temat tego, jak to oczekiwanie może być związane ze spowolnieniem działania aplikacji. Uważam, że jest to kwestia związku przyczynowego. Patrzysz na rosnące oczekiwania i ostatnią skargę użytkownika i wyciągasz wniosek potencjalnie niepoprawnie, że obydwoje mają związek, gdy wcale tak nie jest. Fakt, że dodałeś pliki tempdb, a twoja aplikacja stała się bardziej wrażliwa na mnie, wskazuje, że mogłeś mieć pewne podstawowe problemy rywalizacji, które mogły zostać zaostrzone przez dodatkowe obciążenie wynikające z domyślnego poziomu izolacji migawki, gdy baza danych znajduje się w grupie dostępności. To mogło mieć niewiele lub nic wspólnego z Twoimi oczekiwaniami HADR_SYNC_COMMIT.

Jeśli chcesz to przetestować, możesz użyć rozszerzonego śledzenia zdarzeń, które sprawdza XEvent hadr_db_commit_mgr_update_harden w podstawowej replice i uzyskać linię bazową. Po ustaleniu linii bazowej możesz ponownie dodawać repliki pojedynczo i sprawdzać zmiany śledzenia. Gorąco zachęcam do korzystania z pliku znajdującego się na woluminie, który nie zawiera żadnych baz danych oraz do ustawienia najazdu i maksymalnego rozmiaru. Dostosuj odpowiednio filtr czasu trwania, aby zbierać zdarzenia pasujące do Twoich oczekiwań, abyś mógł dalej rozwiązywać problemy i korelować je z innymi zespołami, które muszą być zaangażowane.

CREATE EVENT SESSION [HADR_SYNC_COMMIT-Monitor] ON SERVER  -- Run this on the primary replica 
ADD EVENT sqlserver.hadr_db_commit_mgr_update_harden(
    WHERE ([delay]>(10))) -- I strongly encourage you to use the delay filter to avoid getting too many events back, this is measured in milliseconds
ADD TARGET package0.event_file(SET filename=N'<YourFilePathHere>')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO