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

Platí pro:Azure SQL Database

Při řešení problémů s výkonem v databázi Hyperscale je výchozím bodem jakéhokoli šetření výkonu obecné metodologie ladění výkonu SQL,. 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.

Snížené čekání na protokoly

Každá databáze a elastický fond ve službě Azure SQL Database spravuje rychlost generování protokolů prostřednictvím zásad správného řízení rychlosti protokolů . Limit rychlosti protokolu je zpřístupněn ve primary_max_log_rate sloupci v sys.dm_user_db_resource_governance.

Občas musí být rychlost generování protokolů na primární replice snížena, aby se zachovala smlouva o úrovni služeb (SLA) obnovitelnosti. K tomu může dojít například tehdy, když je stránkovací server nebo jiná výpočetní replika výrazně pozadu v aplikování nových záznamů protokolu ze služby protokolů. Pokud nejsou za Hyperscale komponenty, mechanismus řízení rychlosti protokolů umožňuje, aby rychlost generování logů dosáhla 150 MiB/s na databázi pro hardware optimalizovaný pro řadu Premium a paměťově optimalizovanou řadu Premium. U hardwaru standardní řady je maximální rychlost protokolů 100 MiB/s na databázi. U elastických fondů je maximální rychlost protokolu 150 MiB/s na fond pro paměť optimalizovaný pro řadu Premium a Premium-series a 125 MiB/s na fond pro jiný hardware.

Při snížené rychlosti protokolu se v sys.dm_os_wait_stats zobrazí následující typy čekání:

Typ čekání	Důvod
`RBIO_RG_STORAGE`	Zpožděná spotřeba protokolů stránkovacím serverem
`RBIO_RG_DESTAGE`	Zpožděná spotřeba protokolů z dlouhodobého úložiště protokolů
`RBIO_RG_REPLICA`	Zpožděná spotřeba logů sekundární replikou v prostředí vysoké dostupnosti nebo pojmenovanou replikou
`RBIO_RG_GEOREPLICA`	Zpožděné zpracování protokolů geografickou sekundární replikou
`RBIO_RG_DESTAGE`	Zpožděná konzumace logů logovací službou
`RBIO_RG_LOCALDESTAGE`	Zpožděná konzumace logů logovací službou
`RBIO_RG_STORAGE_CHECKPOINT`	Zpožděné využití protokolů stránkovacím serverem kvůli pomalému kontrolnímu bodu databáze
`RBIO_RG_MIGRATION_TARGET`	Zpožděná spotřeba protokolů databází, které nejsou HyperScale, během zpětné migrace.

Funkce dynamické správy (DMF ) sys.dm_hs_database_log_rate() poskytuje další podrobnosti, které vám pomůžou pochopit snížení rychlosti protokolů, pokud existuje. Například vám může říci, která konkrétní sekundární replika zaostává v aplikaci záznamů protokolu a jaká je celková velikost transakčního protokolu, který dosud nebyl aplikován.

Čtení stránkového serveru

Výpočetní repliky neupamějují úplnou kopii databáze místně. Data místní k výpočetní replice jsou uložená ve fondu vyrovnávací paměti (v paměti) a v rozšíření mezipaměti fondu místních rezilientních vyrovnávacích pamětí (RBPEX), která obsahuje podmnožinu nejčastěji přistupovaných datových stránek. Tato místní mezipaměť SSD je úměrná velikosti výpočetních prostředků. Každý stránkový server má kompletní mezipaměť SSD pro část databáze, kterou spravuje.

Když je na výpočetní replice vydáno čtecí IO a data nejsou ve fondu vyrovnávací paměti ani v místní mezipaměti SSD, stránka na požadovaném pořadové číslo protokolu (LSN) se načte z odpovídajícího stránkovacího serveru. Čtení ze stránkových serverů jsou vzdálená a jsou pomalejší než čtení z místní mezipaměti SSD. Při řešení problémů s výkonem, které souvisejí s operacemi vstup/výstup, musíme být schopni zjistit, kolik I/O operací bylo provedeno prostřednictvím relativně pomalejšího načítání stránkového serveru.

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á čtení serveru stránek ve statistikách běhu dotazu.

Sloupce pro čtení ze serveru stránek jsou k dispozici v dynamických pohledech správy provádění a v pohledech katalogu.
Pole pro čtení stránkového serveru jsou přítomná v následujících rozšířených událostech:
- sql_statement_completed
- sp_statement_completed
- sql_batch_completed
- rpc_completed
- scan_stopped
- query_store_begin_persist_runtime_stat
- query_store_execution_runtime_info
ActualPageServerReads / ActualPageServerReadAheads atributy jsou přítomné v xml plánu dotazu pro plány, které obsahují statistiky modulu runtime. Například:
```
<RunTimeCountersPerThread Thread="8" ActualRows="90466461" [...] ActualPageServerReads="0" ActualPageServerReadAheads="5687297" ActualLobPageServerReads="0" ActualLobPageServerReadAheads="0" />
```
Spropitné

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í

Ve službě Azure SQL Database je sys.dm_io_virtual_file_stats() DMF jedním ze způsobů, jak monitorovat vstupně-výstupní statistiky databáze, jako jsou IOPS, propustnost a latence. Charakteristiky vstupně-výstupních operací v Hyperscale se liší díky distribuované architektuře. V této části se zaměříme na vstupně-výstupní operace čtení a zápisu, jak je vidět v tomto zobrazení DMF.

V případě Hyperscale jsou relevantní data následující sys.dm_io_virtual_file_stats() :

Řádky, ve database_id kterých hodnota odpovídá hodnotě vrácené funkcí DB_ID a kde file_id hodnota je jiná než 2, odpovídají stránkovým serverům. Každý řádek obvykle odpovídá jednomu stránkkovému serveru. U větších souborů se ale používá více stránkových serverů.
- Řádek se file_id 2 odpovídá transakčnímu protokolu.
Řádky, ve kterých je hodnota ve database_id sloupci 0, odpovídají místní mezipaměti SSD na výpočetní replice.

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

Protože místní mezipaměť SSD existuje na stejném výpočetním uzlu, kde databázový stroj zpracovává dotazy, je vstupně-výstupní operace vůči této mezipaměti rychlejší než vůči stránkovacím serverům. V databázi Hyperscale nebo elastickém fondu má speciální řádky, sys.dm_io_virtual_file_stats() které hlásí vstupně-výstupní statistiky pro místní mezipaměť SSD. Tyto řádky mají hodnotu 0 pro sloupec database_id. Následující dotaz například vrátí statistiky vstupně-výstupních operací místní mezipaměti SSD od spuštění databáze.

SELECT *
FROM sys.dm_io_virtual_file_stats(0, NULL);

Poměr agregovaných čtení z místních souborů mezipaměti SSD k agregovaným čtením ze všech ostatních datových souborů je poměr přístupů do místní mezipaměti SSD. Tuto metriku poskytují čítače výkonu RBPEX cache hit ratio a RBPEX cache hit ratio base, které jsou dostupné v zobrazení dynamické správy sys.dm_os_performance_counters.

Čtení dat

Pokud databázový stroj provádí čtení na výpočetní replice, může je obsloužit buď místní mezipaměť SSD, nebo stránkové servery, případně kombinace obou, pokud se čte více stránek.
Když výpočetní replika načte některé stránky z konkrétního datového souboru (například soubor s file_id 1), pokud se tato data nacházejí výhradně v místní mezipaměti SSD, všechny vstupně-výstupní operace pro toto čtení se započítává do místních souborů mezipaměti SSD, kde database_id je 0. Pokud jsou některá část těchto dat v místní mezipaměti SSD a některá část je na stránkových serverech, vstupně-výstupní operace se započítávají částečně směrem k místním souborům mezipaměti SSD a částečně směrem k datovým souborům odpovídajícím stránkovaným serverům.
Když výpočetní replika požádá o stránku na konkrétním LSN ze stránkového serveru, pokud server stránky ještě nedosáhl požadovaného LSN, čtení na výpočetní replice počká, dokud stránkový server tohoto LSN nedosáhne, a poté je stránka vrácena. U jakéhokoli čtení ze stránkového serveru na výpočetní replice se zobrazí PAGEIOLATCH_* typ čekání, pokud č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 jsou čtení dopředu, se často provádí pomocí bodového shromažďování čtení. To umožňuje čtení až 4 MB v rámci jedné vstupně-výstupní operace čtení. Když jsou data čtena z místní mezipaměti SSD, tato čtení jsou považována za více jednotlivých 8-KB čtení, protože fond vyrovnávací paměti a místní mezipaměť SSD vždy používají 8-KB stránky. Výsledkem je, že počet IO operací pro čtení zachycených proti místní mezipaměti SSD může převyšovat skutečný počet IO operací prováděných systémem.

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řehrají na odpovídajících stránkových serverech.
Zápisy na výpočetní repliku jsou převážně zápisy do místní mezipaměti SSD (database_id 0). Pro zápisy, které jsou větší než 8 kB, tedy ty, které se provádějí pomocí technologie gather-write, je každá operace zápisu rozdělena do více jednotlivých zápisů po 8 kB do lokální vyrovnávací paměti SSD, protože fond vyrovnávací paměti a lokální vyrovnávací paměť SSD vždy používají stránky o velikosti 8 kB. Výsledkem je, že počet IO zápisu, který se zobrazuje v místní mezipaměti SSD, může být větší než skutečný počet IO provedených modulem.
Datové soubory jiné než database_id 0, které odpovídají stránkovým serverům, můžou také zobrazovat zápisy. V Hyperscale se tyto zápisy simulují, protože výpočetní repliky nikdy nezapisují přímo na stránkové servery. V/V statistiky se počítají tak, jak se vyskytují na výpočetní replice. Vstupně-výstupní operace zápisu, propustnost a latence zobrazené na výpočetní replice pro jiné datové soubory než database_id 0 neodráží skutečné vstupně-výstupní statistiky zápisů, ke kterým dochází na stránkových serverech.

Zápisy protokolů

Na primární výpočetní replice se zápisy protokolů započítávají do sys.dm_io_virtual_file_stats()file_id 2.
Na rozdíl od skupin dostupnosti, když dojde k potvrzení transakce na primární výpočetní replice, záznamy protokolu nejsou ukládány na sekundární repliku. V Hyperscale je protokol ve službě protokolů posílen a používá se u sekundárních replik asynchronně. Jelikož zápisy do protokolu ve skutečnosti na sekundárních replikách neprobíhají, nemělo by se vycházet z žádného účtování I/O operací protokolu v sys.dm_io_virtual_file_stats() na sekundárních replikách jako ze statistik transakčního protokolu I/O.

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

V databázi mimo Hyperscale jsou kombinované vstupně-výstupní operace čtení a zápisu proti datovým souborům vzhledem k limitu vstupně-výstupních operací 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. Odpovídající zobrazení dynamické správy pro elastické fondy jsou sys.dm_elastic_pool_resource_stats a sys.elastic_pool_resource_stats. Stejné hodnoty jsou hlášeny jako procento vstupně-výstupních operací dat a jako metriky služby Azure Monitor pro databáze a elastické pooly.

V databázi Hyperscale tyto sloupce a metriky informují o využití datových IO operací vzhledem k limitu pro místní SSD úložiště pouze na výpočetní replice, která zahrnuje IO vůči místní SSD mezipaměti a tempdb databázi. 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 velikost výpočetních prostředků, abyste zvýšili zásady správného řízení prostředků maximální počet vstupně-výstupních operací za sekundulimitu. V případě řízení prostředků pro čtení a zápisy místní mezipaměti SSD systém počítá jednotlivé IOs o velikosti 8 kB, nikoli větší IOs, které může vydat databázový stroj.

Vstupně-výstupní operace dat proti stránkovým serverům nejsou hlášeny v zobrazeních využití prostředků ani prostřednictvím metrik služby Azure Monitor, ale jsou hlášeny sys.dm_io_virtual_file_stats() podle popisu výše.

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-11-05