Przyjazne dla przepustowości profilowanie zapytań dla Azure SQL Database

SQL Server zawsze zapewniał możliwość przechwytywania zapytań na żywo w trybie ad hoc w łatwym do wykorzystania formacie zestawu wierszy — najpierw za pomocą starszego programu SQL Server Profiler, a później za pomocą rozszerzonych zdarzeń w SSMS. Ta funkcja jest przydatna podczas dostrajania wydajności, ponieważ zdarzenia zapytania obejmują dyskretne metryki procesora CPU i we/wy, a także parametry środowiska wykonawczego, które są kluczowe w rozwiązywaniu problemów z wydajnością zapytań, takich jak wykrywanie parametrów. Ponadto zdarzenia zapytań zawierają inne ważne elementy, takie jak nazwa hosta klienta, nazwa aplikacji, login, identyfikator procesu Windows itp.

Zawsze możesz pobrać zagregowane wskaźniki wydajności dla znormalizowanych zapytania z DMV lub Query Store, ale zawierają tylko skompilowane parametrów i żadnego z wyżej wymienionych elementów. Chociaż jest to pomocne, to nie to samo. Na przykład, jeśli chcesz zobaczyć konkretną kombinację parametrów używaną przez to zapytanie, które wykonało 2 miliardy odczytów, lub znaleźć aplikację, która najbardziej obciąża procesor CPU w ciągu ostatnich 24 godzin, nie masz szczęścia.

Azure SQL Database nie jest obsługiwana przez starszy program Profiler, a firma Microsoft wyłączyła dostawcę przesyłania strumieniowego XEvents (sys.fn_MSxe_read_event_stream TVF) ze względu na niezawodność, więc nie można rozkręcić sesji XE i „oglądać danych na żywo” za pomocą programu SSMS. Query Performance Insights w Azure Portal jest wspierany przez Query Store, więc ponownie masz tylko znormalizowane zapytania i zagregowane dane dotyczące wydajności, a nie rzeczywiste zdarzenia zapytań.

Tak więc przez kilka lat utknęliśmy — jedyną opcją profilowania Azure SQL Database było ręczne utworzenie śladu XEvents, który zapisuje w buforze pierścieniowym lub pliku docelowym za pomocą usługi Azure Storage, z których żadna nie jest optymalna. Używanie bufora pierścieniowego z zapytaniami T-SQL może być problematyczne ze względu na ograniczenie formatu XML do 4 MB, o którym mówi tutaj Jonathan Kehayias, a cele plików wymagają sporej ilości przeskakiwania i dodatkowych kosztów. Oba wymagają ręcznego odpytywania danych XE, a więc nie są dokładnie „na żywo” w tradycyjnym sensie.

Wpisz Nowe Profiler serwera SQL

Kiedy dowiedziałem się o rozszerzeniu SQL Server Profiler dla Azure Data Studio, z przyjemnością zobaczyłem, że Microsoft w końcu dostarczył graficzne rozwiązanie do przechwytywania zapytań na żywo w Azure SQL Database. Niestety moje podekscytowanie było krótkotrwałe z kilku powodów.

Po pierwsze, przerażający „standardowy” ślad ze starszego programu Profiler został najwyraźniej użyty jako model dla sesji ADS Profiler XE dla Azure SQL Database , o nazwie ADS_Standard_Azure domyślnie. (Sesje XE używane dla pełnego programu SQL Server są podobne.) Jak kilka lat temu pisałem na blogu i nadal wierzę, śledzenie standardowe jest głównym powodem, dla którego starszy Profiler jest tak słabo postrzegany. Zawiera wiele bezużytecznych i niefiltrowanych zdarzeń, takich jak start wsadowy SQL , zaloguj się i wyloguj się , aw rezultacie nie dodaje żadnej rzeczywistej wartości do dostrajania wydajności. Co więcej, dzięki architekturze synchronicznego śledzenia zestawu wierszy używanej przez starszy program Profiler, duża liczba zdarzeń może wpływać na wydajność w obciążonych systemach. Z jakiegoś powodu to nie zniknie!


*Zdarzenia śledzenia „Standardowe” starszego narzędzia Profiler*	Zdarzenia XE programu ADS Profiler „ADS_Standard_Azure” – wyglądasz znajomo?

Po drugie, używa bufora pierścieniowego o maksymalnym rozmiarze 8 MB lub 1000 zdarzeń, w zależności od tego, co nastąpi wcześniej. Ponieważ zdarzenia logowania/wylogowania są małe, często trafisz na 1000 zdarzeń na długo przed osiągnięciem limitu 8 MB, a nawet 4 MB w formacie XML. Jednak przy umiarkowanej mieszance zdarzeń SQL, XML bufora pierścieniowego nadal będzie miał od 2 do 3 MB przy 1000 zdarzeniach w moich testach, a problem polega na tym, że cały bufor jest przeciągany przez sieć za każdym razem, gdy rozszerzenie Profiler odpytuje w celu odświeżenia jego siatka , który jest dłuższy z każdej 1 sekundy lub czasu trwania poprzedniej ankiety. XML jest następnie analizowany po stronie klienta przez rozszerzenie ADS Profiler, aby określić, które zdarzenia są nowe od ostatniego sondowania, a nowe zdarzenia są dodawane do siatki.

Bufor pierścieniowy zapełnia się niemal natychmiast nawet na średnio obciążonym serwerze, a efektem netto jest to, że szybko będziesz pobierać przez sieć>40 megabitów na sekundę z bazy danych SQL Azure . Przekłada się to na 300 megabajtów na minutę lub 18 gigabajtów na godzinę!

Udział w sieci z rozszerzenia ADS Profiler (zakres 4 minut)

Początkowo obawiałem się, że może to prowadzić do ogromnych opłat za ruch wychodzący na następnym rachunku za Azure, jednak patrząc na nasze własne subskrypcje Azure nie byliśmy w stanie potwierdzić, że ruch sieciowy dla Azure SQL DB jest naliczany. Mike Wood (b|t) z SentryOne, specjalista Azure MVP, spędził tygodnie próbując znaleźć odpowiedź i w końcu otrzymał wiadomość od Microsoftu, że rzeczywiście za ruch wychodzący z sieci nie jest obecnie pobierana opłata za Azure SQL DB, chociaż może się to zmienić w dowolnym momencie. Mimo to ściąganie 18 GB danych zapytań na godzinę nie wydaje się odpowiedzialne i z pewnością może utrudnić kolejną sesję oglądania na Netflix.

Chociaż możesz ustawić filtry w interfejsie użytkownika Profilera, który ułatwi przeglądanie danych, nie zmniejszy to trafienia w sieć, ponieważ działają one po stronie klienta.

Zaktualizowana sesja XE

Szybkim rozwiązaniem pozwalającym na zmniejszenie obciążenia sieci przez narzędzie ADS Profiler i zwiększenie użyteczności danych do dostrajania wydajności zapytań jest aktualizacja ADS_Standard_Azure Sesja XE. Poniżej znajduje się skrypt, który:

Usuń niepotrzebne wydarzenia:
- sqlserver.uwaga
- sqlserver.istniejące_połączenie
- sqlserver.login
- sqlserver.logout
- sqlserver.sql_batch_starting
Ustaw próg czasu trwania> 1 sekundy (1000000 mikrosekund) dla pozostałych zdarzeń:
- sqlserver.rpc_completed
- sqlserver.sql_batch_completed
Zmniejsz maksymalny rozmiar bufora pierścieniowego z 1000 do 10 zdarzeń
- To nigdy nie zadziałałoby z oryginalnym śledzeniem, ponieważ 10 zdarzeń zostanie wygenerowanych w ciągu milisekund, a bufor pierścieniowy będzie się zbyt szybko reagował, powodując utratę większości zdarzeń. Jednak w przypadku filtru czasu trwania 1-sekundowego przepływ zdarzeń będzie znacznie mniejszy, a 10 zdarzeń powinno działać dobrze z 1-sekundowym interwałem sondowania używanym przez profiler ADS.

ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE 
DROP EVENT sqlserver.attention,
DROP EVENT sqlserver.existing_connection,
DROP EVENT sqlserver.login,
DROP EVENT sqlserver.logout,
DROP EVENT sqlserver.rpc_completed,
DROP EVENT sqlserver.sql_batch_completed,
DROP EVENT sqlserver.sql_batch_starting
GO
 
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE 
ADD EVENT sqlserver.rpc_completed(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.client_pid,sqlserver.database_id,sqlserver.query_hash,sqlserver.session_id,sqlserver.username)
      WHERE (([package0].[equal_boolean]([sqlserver].[is_system],(0))) AND ([duration] >= (1000000)))),
ADD EVENT sqlserver.sql_batch_completed(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.client_pid,sqlserver.database_id,sqlserver.query_hash,sqlserver.session_id,sqlserver.username)
      WHERE (([package0].[equal_boolean]([sqlserver].[is_system],(0))) AND ([duration] >= (1000000))))
GO
 
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE 
DROP TARGET package0.ring_buffer
GO
 
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE 
ADD TARGET package0.ring_buffer(SET max_events_limit=(10),max_memory=(51200))
GO

Po zastosowaniu skryptu do aktualizacji sesji XE, wąż strażacki zostanie natychmiast zredukowany do strumyka:

Zmniejszone trafienie w sieć po aktualizacji sesji ADS Profiler XE

Jeszcze lżejsze alternatywy

SQL Sentry i jego odpowiednik SaaS SentryOne Monitor to jedyne inne znane mi rozwiązania do przechwytywania zapytań z Azure SQL Database, a robią to przy użyciu innowacyjnego podejścia, które jest znacznie lżejsze niż zoptymalizowana powyżej sesja XE dla ADS Profiler. Wśród innych zaawansowanych funkcji można łatwo agregować według nazwy hosta klienta, aplikacji i loginu oraz automatycznie przechwytywać plany zapytań do analizy za pomocą zintegrowanego Eksploratora planów.

SentryOne Monitor wyświetlający przechwycone zapytania i plany z bazy danych Azure SQL

Zamykanie

Microsoft oświadczył, że będzie nadal ulepszać rozszerzenie ADS Profiler, a kiedy to zrobią, mam nadzieję, że rozwiążą problemy opisane powyżej. Zalogowałem ten problem tutaj. W międzyczasie zaktualizowany skrypt zapewni bezpieczniejsze i bardziej przyjazne dla przepustowości środowisko profilowania zapytań dla Azure SQL Database.