Udostępnij za pośrednictwem

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, może być konieczne rozważenie dodatkowych danych diagnostycznych. 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. Szybkość generowania dzienników wynosząca 150 MB/s jest dostępna jako funkcja w wersji zapoznawczej. Aby uzyskać więcej informacji i wyrazić zgodę na 150 MB/s, zobacz Blog: listopad 2024 r. Ulepszenia 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óźnienia użycia dziennika przez co najmniej jeden serwer stronicowania.
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ła obliczeniowego bazy danych hiperskala jest ograniczana z powodu opóźnienia użycia dziennika przez co najmniej jedną replikę pomocniczą 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 (w pamięci) i w lokalnej odpornej pamięci podręcznej puli (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. RBPEX jest podobny do puli, 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 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. Na 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 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 oczekuje 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 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 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/wy na 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