Sdílet prostřednictvím

Diagnostika řešení potíží s výkonem SQL Hyperscale

  • Článek

Platí pro: Azure SQL Database

Při řešení potíží s výkonem v databázi Hyperscale jsou výchozím bodem šetření výkonu obecné metodologie ladění výkonu na výpočetním uzlu služby Azure SQL Database. Vzhledem k distribuované architektuře hyperškálování ale může být potřeba zvážit další diagnostická data. Tento článek popisuje diagnostická data specifická pro Hyperscale.

Čekání omezování rychlosti protokolů

Každý cíl služby Azure SQL Database má vynucené limity rychlosti generování protokolů prostřednictvím zásad správného řízení rychlosti protokolů. V Hyperscale je limit zásad správného řízení protokolu nastavený na 105 MB/s bez ohledu na úroveň služby. Tato hodnota se zobrazí ve sloupci primary_max_log_rate v sys.dm_user_db_resource_governance.

V době, kdy je však potřeba omezovat rychlost generování protokolů na primární výpočetní replice, aby se zachovala smlouva SLA pro obnovitelnost. K tomuto omezování dochází v případě, že stránkovací server nebo jiná výpočetní replika výrazně za použití nových záznamů protokolu ze služby protokolů. Pokud nejsou za sebou žádné stránkovací servery nebo repliky, mechanismus omezování umožňuje rychlost generování protokolů dosáhnout 100 MB/s. Jedná se o efektivní maximální rychlost generování protokolů ve všech cílech služby Hyperscale. Rychlost generování protokolů 150 MB/s je dostupná jako funkce opt-in Preview. Další informace a vyjádření souhlasu s 150 MB/s najdete v blogu : Vylepšení hyperškálování z listopadu 2024.

Následující typy čekání (v sys.dm_os_wait_stats) popisují důvody, proč může být rychlost protokolu omezena na primární repliku výpočetních prostředků:

Typ čekání Popis
RBIO_RG_STORAGE Nastane, když dochází k omezování rychlosti generování protokolů primárního výpočetního uzlu databáze Hyperscale kvůli zpožděné spotřebě protokolů jedním nebo více stránkovými servery.
RBIO_RG_DESTAGE Nastane, když dochází k omezování rychlosti generování protokolů výpočetních uzlů databáze Hyperscale kvůli zpožděné spotřebě protokolů úložištěm protokolů z dlouhodobého hlediska.
RBIO_RG_REPLICA Nastane, když dochází k omezování rychlosti generování protokolů výpočetních uzlů databáze Hyperscale kvůli zpožděné spotřebě protokolů jednou nebo více čitelnými sekundárními replikami.
RBIO_RG_GEOREPLICA Nastane, když je rychlost generování protokolů výpočetních uzlů databáze Hyperscale omezena kvůli zpožděné spotřebě protokolů sekundární replikou.
RBIO_RG_LOCALDESTAGE Nastane, když dochází k omezování rychlosti generování protokolů výpočetních uzlů databáze Hyperscale kvůli zpožděné spotřebě protokolů službou protokolů.

Čtení stránkového serveru

Výpočetní repliky neupamějte úplnou kopii databáze místně. Data místní pro výpočetní repliku jsou uložená ve fondu vyrovnávací paměti (v paměti) a v místní odolné mezipaměti fondu vyrovnávací paměti (RBPEX), která je částečnou (nekrývající) mezipamětí datových stránek. Tato místní mezipaměť RBPEX je úměrná velikosti výpočetní velikosti. RBPEX je podobný fondu vyrovnávací paměti v tom, že má nejčastěji přístupná data. Každý stránkový server má na druhé straně krytou mezipaměť RBPEX pro část databáze, která udržuje.

Pokud je na výpočetní replice vydáno čtení, pokud data ve fondu vyrovnávací paměti nebo místní mezipaměti RBPEX neexistují, je vydáno volání funkce getPage(pageId, LSN) a stránka se načte z odpovídajícího stránkového serveru. Čtení ze stránkových serverů jsou vzdálená čtení a jsou tak pomalejší než čtení z místního RBPEXu. Při řešení problémů s výkonem souvisejících se vstupně-výstupními operacemi musíme být schopni zjistit, kolik vstupně-výstupních operací bylo provedeno prostřednictvím relativně pomalejších čtení vzdáleného serveru stránky.

Několik dynamickýchspravovaných událostí (DMV) a rozšířených událostí obsahuje sloupce a pole, které určují počet vzdálených čtení ze stránkového serveru, které lze porovnat s celkovým čtením. Úložiště dotazů také zaznamenává vzdálené čtení jako součást statistik doby běhu dotazu.

  • Sloupce serveru stránek sestav jsou k dispozici v zobrazeních dynamické správy spouštění a v zobrazeních katalogu, například:

  • Čtení stránkového serveru se přidává do následujících rozšířených událostí:

    • sql_statement_completed
    • sp_statement_completed
    • sql_batch_completed
    • rpc_completed
    • scan_stopped
    • query_store_begin_persist_runtime_stat
    • store_execution_runtime_info dotazu

  • ActualPageServerReads/ActualPageServerReadAheads se přidají do kódu XML plánu dotazu pro skutečné plány. Příklad:

<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" />

Poznámka:

Chcete-li zobrazit tyto atributy v okně vlastností plánu dotazu, vyžaduje se SSMS 18.3 nebo novější.

Statistiky virtuálních souborů a účtování vstupně-výstupních operací

V Azure SQL Database je dmF sys.dm_io_virtual_file_stats() primárním způsobem monitorování vstupně-výstupních operací služby SQL Database. Charakteristiky vstupně-výstupních operací v Hyperscale se vzhledem k distribuované architektuře liší. V této části se zaměříme na vstupně-výstupní operace (čtení a zápisy) do datových souborů, jak je vidět v tomto DMF. V hyperškálování každý datový soubor viditelný v tomto dmF odpovídá vzdálenému stránkovém serveru. Zde uvedená mezipaměť RBPEX je místní mezipaměť založená na ssd, která není krytou mezipamětí na výpočetní replice.

Využití místní mezipaměti RBPEX

Místní mezipaměť RBPEX existuje na výpočetní replice v místním úložišti SSD. Vstupně-výstupní operace proti této mezipaměti je tedy rychlejší než vstupně-výstupní operace vůči vzdáleným stránkám serverů. V současné době má sys.dm_io_virtual_file_stats() v databázi Hyperscale speciální řádek, který hlásí vstupně-výstupní operace vůči místní mezipaměti RBPEX na výpočetní replice. Tento řádek má hodnotu 0 pro oba database_id sloupce i file_id sloupce. Například následující dotaz vrátí statistiku využití RBPEX od spuštění databáze.

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

Poměr čtení provedených u RBPEX k agregovaným čtením provedeným u všech ostatních datových souborů poskytuje poměr přístupů do mezipaměti RBPEX. Čítač RBPEX cache hit ratio je také vystaven v čítačích výkonu DMV sys.dm_os_performance_counters.

Čtení dat

  • Pokud databázový stroj SQL Serveru vydá na výpočetní replice čtení, může je obsluhovat místní mezipaměť RBPEX nebo vzdálené stránkové servery nebo kombinace těchto dvou stránek při čtení více stránek.
  • Když výpočetní replika načte některé stránky z konkrétního souboru, například file_id 1, pokud se tato data nacházejí výhradně v místní mezipaměti RBPEX, všechny vstupně-výstupní operace pro toto čtení se započítá do file_id 0 (RBPEX). Pokud jsou některá část těchto dat v místní mezipaměti RBPEX a část je na vzdáleném stránkovém serveru, vstupně-výstupní operace se započítá do file_id 0 pro část obsluhovanou z RBPEX a část obsluhovaná ze vzdáleného serveru stránky se započítá do file_id 1.
  • Když výpočetní replika požádá o stránku na konkrétním LSN ze stránkového serveru, pokud server stránky nedosáhl požadovanému LSN, čtení na výpočetní replice počká, dokud se stránkový server nevrátí do výpočetní repliky. U jakéhokoli čtení ze stránkového serveru na výpočetní replice se zobrazí typ čekání PAGEIOLATCH_* v případě, že čeká na dané vstupně-výstupní operace. V Hyperscale zahrnuje tato doba čekání jak čas na zachycení požadované stránky na serveru stránky do požadovaného LSN, tak i doba potřebná k přenosu stránky ze serveru stránky do repliky výpočetních prostředků.
  • Velká čtení, jako je čtení dopředu, se často provádí pomocí čtení "Bodové shromáždění". To umožňuje čtení až 4 MB stránek najednou, což je považováno za jediné čtení v databázovém stroji SQL Serveru. Při čtení dat v RBPEX jsou však tato čtení zohledněny jako více čtení 8 kB, protože fond vyrovnávací paměti a RBPEX vždy používají 8kB stránky. V důsledku toho může být počet IO přečtených oproti RBPEX větší než skutečný počet IO provedených modulem.

Zápisy dat

  • Primární výpočetní replika nezapisuje přímo na stránkové servery. Místo toho se záznamy protokolu ze služby protokolů přehrávají na odpovídajících stránkových serverech.
  • Zápisy, ke kterým dochází na výpočetní replice, jsou převážně zápisy do místního RBPEX (file_id 0). Pro zápisy do logických souborů, které jsou větší než 8 kB, jinými slovy ty, které se provádějí pomocí indexovacího zápisu, se každá operace zápisu přeloží do více 8kB jednotlivých zápisů do RBPEX, protože fond vyrovnávací paměti a RBPEX vždy používají 8kB stránky. Výsledkem je, že počet IO zápisu, které se zobrazují u RBPEX, může být větší než skutečný počet IO provedených modulem.
  • Jiné soubory než RBPEX nebo jiné datové soubory než file_id 0, které odpovídají stránkovým serverům, zobrazují také zápisy. Ve vrstvě služby Hyperscale se tyto zápisy simulují, protože výpočetní repliky nikdy nezapisují přímo na stránkové servery. Vstupně-výstupní operace zápisu a propustnost se počítají při jejich výskytu na výpočetní replice, ale latence pro jiné datové soubory než file_id 0 neodráží skutečnou latenci zápisů stránkového serveru.

Zápisy protokolů

  • Na primárním výpočetním objektu se zapisuje protokol v file_id 2 sys.dm_io_virtual_file_stats. Zápis protokolu na primární výpočetní prostředky je zápis do cílové zóny protokolu.
  • Záznamy protokolu nejsou v sekundární replice při potvrzení posíleny. V Hyperscale se protokol použije službou protokolů na sekundární repliky asynchronně. Vzhledem k tomu, že zápisy protokolů ve skutečnosti na sekundárních replikách nenastanou, je jakékoli účtování IO protokolů na sekundárních replikách určené pouze pro účely sledování.

Vstupně-výstupní operace dat ve statistikách využití prostředků

V databázi bez hyperškálování jsou kombinované vstupně-výstupní operace čtení a zápisu proti datovým souborům vzhledem k limitu IOPS zásad správného řízení prostředků hlášeny v zobrazeních sys.dm_db_resource_stats a sys.resource_stats ve avg_data_io_percent sloupci. Stejná hodnota se na webu Azure Portal hlásí jako procento vstupně-výstupních operací dat.

V databázi Hyperscale tento sloupec hlásí využití IOPS dat vzhledem k limitu pro místní úložiště pouze na výpočetní replice, konkrétně vstupně-výstupní operace proti RBPEX a tempdb. Hodnota 100 % v tomto sloupci označuje, že zásady správného řízení prostředků omezují IOPS místního úložiště. Pokud se jedná o korelaci s problémem s výkonem, vylaďte úlohu tak, aby generovala méně vstupně-výstupních operací, nebo zvyšte cíl databázové služby, abyste zvýšili limit maximálního počtu vstupně-výstupních operací za sekundu v rámci zásad správného řízení prostředků. V případě zásad správného řízení prostředků pro čtení a zápisy RBPEX systém počítá jednotlivé IOS 8 kB, nikoli větší IO, které může vydat databázový stroj SQL Serveru.

Vstupně-výstupní operace vstupně-výstupních operací na vzdálených stránkových serverech nejsou hlášeny v zobrazeních využití prostředků ani na portálu, ale jsou hlášeny v sys.dm_io_virtual_file_stats() DMF, jak je uvedeno výše.

Další materiály