Diagnostyka rozwiązywania problemów z wydajnością bazy danych SQL w warstwie Hiperskala

  • Artykuł

Dotyczy:Azure SQL Database

Aby rozwiązać problemy z wydajnością w bazie danych hiperskala, ogólne metodologie dostrajania wydajności w węźle obliczeniowym usługi Azure SQL Database to punkt początkowy badania wydajności. Jednak biorąc pod uwagę architekturę rozproszoną warstwy Hiperskala, dodano dodatkową diagnostykę w celu ułatwienia. W tym artykule opisano dane diagnostyczne specyficzne dla hiperskala.

Oczekiwania na ograniczanie szybkości rejestrowania

Każdy cel usługi Azure SQL Database ma limity szybkości generowania dzienników wymuszane za pośrednictwem ładu szybkości dzienników. W warstwie Hiperskala limit nadzoru dziennika jest ustawiony na 105 MB/s, niezależnie od poziomu usługi. Ta wartość jest widoczna w kolumnie primary_max_log_rate w sys.dm_user_db_resource_governance.

Jednak czasami szybkość generowania dziennika w podstawowej replice obliczeniowej musi być ograniczona, aby zachować umowy SLA dotyczące możliwości odzyskiwania. To ograniczenie występuje, gdy serwer strony lub inna replika obliczeniowa znacznie polega na zastosowaniu nowych rekordów dziennika z usługi dziennika. Jeśli nie ma serwerów stron ani replik, mechanizm ograniczania zezwala na szybkość generowania dzienników do osiągnięcia 100 MB/s. Jest to efektywna maksymalna szybkość generowania dzienników we wszystkich celach usługi Hiperskala.

Następujące typy oczekiwania (w sys.dm_os_wait_stats) opisują przyczyny ograniczania szybkości rejestrowania w podstawowej repliki obliczeniowej:

Typ oczekiwania opis
RBIO_RG_STORAGE Występuje, gdy podstawowa szybkość generowania dziennika węzła obliczeniowego bazy danych w warstwie Hiperskala jest ograniczana z powodu opóźnionego użycia dzienników na serwerach stron.
RBIO_RG_DESTAGE Występuje, gdy szybkość generowania dzienników węzła obliczeniowego bazy danych w warstwie Hiperskala jest ograniczana z powodu opóźnienia użycia dziennika przez długoterminowy magazyn dzienników.
RBIO_RG_REPLICA Występuje, gdy szybkość generowania dzienników węzłów obliczeniowych bazy danych w warstwie Hiperskala jest ograniczana z powodu opóźnienia użycia dziennika przez repliki pomocnicze z możliwością odczytu.
RBIO_RG_GEOREPLICA Występuje, gdy szybkość generowania dzienników węzłów obliczeniowych bazy danych w warstwie Hiperskala jest ograniczana z powodu opóźnienia użycia dziennika przez replikę pomocniczą geograficzną.
RBIO_RG_LOCALDESTAGE Występuje, gdy szybkość generowania dzienników węzłów obliczeniowych bazy danych w warstwie Hiperskala jest ograniczana z powodu opóźnionego użycia dziennika przez usługę dziennika.

Odczyty serwera stron

Repliki obliczeniowe nie buforują pełnej kopii bazy danych lokalnie. Dane lokalne repliki obliczeniowej są przechowywane w puli buforów (w pamięci) i w lokalnej odpornej pamięci podręcznej puli buforów (RBPEX), która jest częściową (nieskrywającą) pamięcią podręczną stron danych. Ta lokalna pamięć podręczna RBPEX ma proporcjonalny rozmiar do rozmiaru obliczeniowego i jest trzy razy większa niż pamięć warstwy obliczeniowej. RBPEX jest podobny do puli buforów, ponieważ ma najczęściej używane dane. Z drugiej strony każdy serwer stron ma obejmującą pamięć podręczną RBPEX dla części przechowywanej bazy danych.

Jeśli odczyt jest wystawiany w replice obliczeniowej, jeśli dane nie istnieją w puli buforów lub lokalnej pamięci podręcznej RBPEX, zostanie wystawione wywołanie funkcji getPage(pageId, LSN), a strona zostanie pobrana z odpowiedniego serwera strony. Odczyty z serwerów stron są odczytami zdalnymi i dlatego są wolniejsze niż odczyty z lokalnego RBPEX. Podczas rozwiązywania problemów z wydajnością związanych z operacjami we/wy musimy określić, ile operacji we/wy zostało wykonanych za pośrednictwem stosunkowo wolniejszego odczytu serwera stron zdalnych.

Kilka dynamicznych widoków zarządzanych (DMV) i zdarzeń rozszerzonych mają kolumny i pola, które określają liczbę zdalnych odczytów z serwera stron, które można porównać z łączną liczbą odczytów. Magazyn zapytań przechwytuje również zdalne operacje odczytu w ramach statystyk czasu wykonywania zapytania.

  • Kolumny do odczytu serwera stron raportów są dostępne w widokach DMV wykonywania i widokach katalogu, takich jak:

  • Odczyty serwera stron są dodawane do następujących zdarzeń rozszerzonych:

    • sql_statement_completed
    • sp_statement_completed
    • sql_batch_completed
    • rpc_completed
    • scan_stopped
    • query_store_begin_persist_runtime_stat
    • store_execution_runtime_info zapytań

  • Wartości ActualPageServerReads/ActualPageServerReadAheads są dodawane do kodu XML planu zapytania dla rzeczywistych planów. Przykład:

<RunTimeCountersPerThread Thread="8" ActualRows="90466461" ActualRowsRead="90466461" Batches="0" ActualEndOfScans="1" ActualExecutions="1" ActualExecutionMode="Row" ActualElapsedms="133645" ActualCPUms="85105" ActualScans="1" ActualLogicalReads="6032256" ActualPhysicalReads="0" ActualPageServerReads="0" ActualReadAheads="6027814" ActualPageServerReadAheads="5687297" ActualLobLogicalReads="0" ActualLobPhysicalReads="0" ActualLobPageServerReads="0" ActualLobReadAheads="0" ActualLobPageServerReadAheads="0" />

Uwaga

Aby wyświetlić te atrybuty w oknie właściwości planu zapytania, wymagany jest program SSMS 18.3 lub nowszy.

Statystyki plików wirtualnych i ewidencjonowanie operacji we/wy

W usłudze Azure SQL Database sys.dm_io_virtual_file_stats() DMF jest podstawowym sposobem monitorowania operacji we/wy usługi SQL Database. Właściwości operacji we/wy w warstwie Hiperskala różnią się ze względu na architekturę rozproszoną. W tej sekcji skoncentrujemy się na operacji we/wy (odczyty i zapisy) do plików danych, jak pokazano w tym DMF. W warstwie Hiperskala każdy plik danych widoczny w tym DMF odpowiada serwerowi zdalnej strony. Pamięć podręczna RBPEX wymieniona tutaj jest lokalną pamięcią podręczną opartą na dyskach SSD, która nie obejmuje pamięci podręcznej w replice obliczeniowej.

Użycie lokalnej pamięci podręcznej RBPEX

Lokalna pamięć podręczna RBPEX istnieje w replice obliczeniowej w lokalnym magazynie SSD. W związku z tym operacje we/wy względem tej pamięci podręcznej są szybsze niż operacje we/wy na zdalnych serwerach stron. Obecnie sys.dm_io_virtual_file_stats() w bazie danych hiperskala ma specjalny wiersz raportowania operacji we/wy względem lokalnej pamięci podręcznej RBPEX w replice obliczeniowej. Ten wiersz ma wartość 0 dla kolumn database_id i file_id . Na przykład poniższe zapytanie zwraca statystyki użycia RBPEX od momentu uruchomienia bazy danych.

select * from sys.dm_io_virtual_file_stats(0,NULL);

Współczynnik odczytów wykonanych na podstawie RBPEX do zagregowanych odczytów wykonanych we wszystkich innych plikach danych zapewnia współczynnik trafień pamięci podręcznej RBPEX. RBPEX cache hit ratio Licznik jest również uwidoczniony w licznikach wydajności DMV sys.dm_os_performance_counters.

Odczyty danych

  • Gdy odczyty są wydawane przez aparat bazy danych programu SQL Server w replice obliczeniowej, mogą być obsługiwane przez lokalną pamięć podręczną RBPEX lub przez serwery stron zdalnych lub przez kombinację tych dwóch, jeśli odczytuje wiele stron.
  • Gdy replika obliczeniowa odczytuje niektóre strony z określonego pliku, na przykład file_id 1, jeśli te dane znajdują się wyłącznie w lokalnej pamięci podręcznej RBPEX, wszystkie operacje we/wy dla tego odczytu są uwzględniane względem file_id 0 (RBPEX). Jeśli część tych danych znajduje się w lokalnej pamięci podręcznej RBPEX, a część znajduje się na serwerze zdalnym strony, we/wy jest uwzględniana w kierunku file_id 0 dla części obsługiwanej z RBPEX, a część obsługiwana z serwera stron zdalnych jest uwzględniana w stosunku do file_id 1.
  • Gdy replika obliczeniowa żąda strony w określonej sieci LSN z serwera stron, jeśli serwer strony nie został przechwycony do żądanej nazwy LSN , odczyt w replice obliczeniowej będzie czekać, aż serwer strony dogoni, zanim strona zostanie zwrócona do repliki obliczeniowej. W przypadku dowolnego odczytu z serwera stron w replice obliczeniowej zobaczysz typ oczekiwania PAGEIOLATCH_*, jeśli czeka na to we/wy. W warstwie Hiperskala ten czas oczekiwania obejmuje zarówno czas nadrobienia zaległości żądanej strony na serwerze strony do wymaganej nazwy LSN, jak i czasu potrzebnego do przeniesienia strony z serwera stron do repliki obliczeniowej.
  • Duże operacje odczytu, takie jak odczyt do przodu, są często wykonywane przy użyciu odczytów "Zbieranie punktowe". Umożliwia to odczyt do 4 MB stron w danym momencie, uważany za pojedynczy odczyt w a aparatu bazy danych programu SQL Server. Jednak gdy odczyt danych znajduje się w RBPEX, odczyty te są uwzględniane jako wiele pojedynczych odczytów 8 KB, ponieważ pula buforów i RBPEX zawsze używają stron 8 KB. W rezultacie liczba odczytanych operacji we/wy obserwowanych względem RBPEX może być większa niż rzeczywista liczba operacji we/wy wykonywanych przez aparat.

Zapisy danych

  • Podstawowa replika obliczeniowa nie zapisuje bezpośrednio na serwerach stronicowania. Zamiast tego rekordy dzienników z usługi dziennika są odtwarzane na odpowiednich serwerach stron.
  • Zapisy wykonywane w repliki obliczeniowej są głównie zapisywane w lokalnym RBPEX (file_id 0). W przypadku zapisów w plikach logicznych, które są większe niż 8 KB, innymi słowy, wykonywane przy użyciu funkcji Zbieraj i zapisu każda operacja zapisu jest tłumaczona na wiele 8 KB pojedynczych zapisów do RBPEX, ponieważ pula buforów i RBPEX zawsze używają stron 8 KB. W rezultacie liczba operacji we/wy zapisu widocznych względem RBPEX może być większa niż rzeczywista liczba operacji we/wy wykonywanych przez aparat.
  • Pliki inne niż RBPEX lub pliki danych inne niż file_id 0, które odpowiadają serwerom stron, również pokazują zapisy. W warstwie usługi Hiperskala te operacje zapisu są symulowane, ponieważ repliki obliczeniowe nigdy nie zapisują bezpośrednio na serwerach stron. Operacje we/wy zapisu na sekundę i przepływność są uwzględniane w replice obliczeniowej, ale opóźnienie dla plików danych innych niż file_id 0 nie odzwierciedla rzeczywistego opóźnienia operacji zapisu serwera strony.

Zapisy dziennika

  • W przypadku obliczeń podstawowych zapis dziennika jest uwzględniany w file_id 2 z sys.dm_io_virtual_file_stats. Zapis dziennika w podstawowych obliczeniach jest zapisem w strefie docelowej dziennika.
  • Rekordy dziennika nie są wzmacniane w repliki pomocniczej w zatwierdzeniu. W warstwie Hiperskala dziennik jest stosowany przez usługę dziennika do replik pomocniczych asynchronicznie. Ponieważ zapisy dziennika nie występują w replikach pomocniczych, wszystkie operacje we/wy dziennika w replikach pomocniczych są przeznaczone tylko do celów śledzenia.

Dane we/wy w statystykach wykorzystania zasobów

W bazie danych innej niż Hiperskala łączna liczba operacji we/wy odczytu i zapisu na sekundę względem plików danych dotyczących ładu zasobów jest zgłaszana w widokach sys.dm_db_resource_stats i sys.resource_stats w kolumnie avg_data_io_percent . Ta sama wartość jest zgłaszana w witrynie Azure Portal jako wartość procentowa operacji we/wy danych.

W bazie danych hiperskala ta kolumna raportuje wykorzystanie operacji we/wy na sekundę danych względem limitu magazynu lokalnego tylko w przypadku repliki obliczeniowej, w szczególności we/wy względem RBPEX i tempdb. Wartość 100% w tej kolumnie wskazuje, że nadzór nad zasobami ogranicza liczbę operacji we/wy na sekundę magazynu lokalnego. Jeśli jest to skorelowane z problemem z wydajnością, dostosuj obciążenie, aby wygenerować mniej operacji we/wy lub zwiększyć cel usługi bazy danych, aby zwiększyć limit maksymalnej liczby operacji we/wyna sekundę dla ładu zasobów. W przypadku zarządzania zasobami operacji odczytu i zapisu RBPEX system liczy poszczególne operacje we/wy 8 KB, a nie większe operacje we/wy, które mogą być wystawiane przez aparat bazy danych programu SQL Server.

Operacje we/wy danych względem zdalnych serwerów stron nie są zgłaszane w widokach wykorzystania zasobów ani w portalu, ale są zgłaszane w sys.dm_io_virtual_file_stats() DMF, jak wspomniano wcześniej.

Dodatkowe zasoby