Sdílet prostřednictvím

Správa prostředků v hustých elastických fondech

  • Článek

Platí pro: Azure SQL Database

Elastické fondy Azure SQL Database jsou nákladově efektivní řešení pro správu mnoha databází s různým využitím prostředků. Všechny databáze v elastickém fondu sdílejí stejné přidělení prostředků, jako je procesor, paměť, pracovní vlákna, prostor úložiště, za předpokladu, tempdbže v daném okamžiku budou výpočetní prostředky používat pouze podmnožina databází ve fondu. Tento předpoklad umožňuje, aby elastické fondy byly nákladově efektivní. Místo placení za všechny prostředky může každá jednotlivá databáze potenciálně potřebovat, zákazníci platí za mnohem menší sadu prostředků, které jsou sdíleny mezi všemi databázemi ve fondu.

Zásady správného řízení prostředků

Sdílení prostředků vyžaduje, aby systém pečlivě kontroluje využití prostředků, aby minimalizoval efekt "hlučného souseda", kdy databáze s vysokou spotřebou prostředků ovlivňuje jiné databáze ve stejném elastickém fondu. Azure SQL Database tyto cíle dosahuje implementací zásad správného řízení prostředků. Systém současně musí poskytovat dostatečné prostředky pro funkce, jako je vysoká dostupnost a zotavení po havárii (HADR), zálohování a obnovení, monitorování, úložiště dotazů, automatické ladění atd. pro spolehlivé fungování.

Hlavním cílem návrhu elastických fondů je nákladově efektivní. Z tohoto důvodu systém záměrně umožňuje zákazníkům vytvářet zhuštěné fondy, což jsou fondy s počtem databází, které přistupují k maximálnímu nebo maximálnímu povolenému počtu, ale s mírným přidělením výpočetních prostředků. Systém si z stejného důvodu nezarezervuje všechny potenciálně potřebné prostředky pro interní procesy, ale umožňuje sdílení prostředků mezi interními procesy a uživatelskými úlohami.

Tento přístup umožňuje zákazníkům používat zhuštěné elastické fondy k dosažení odpovídajícího výkonu a velkých úspor nákladů. Pokud je však zatížení u mnoha databází v zhuštěném fondu dostatečně intenzivní, dojde k významné kolizí prostředků. Kolize prostředků snižuje výkon uživatelských úloh a může negativně ovlivnit interní procesy.

Důležité

V hustých fondech s mnoha aktivními databázemi nemusí být možné zvýšit počet databází ve fondu až na maximum zdokumentované pro elastické fondy DTU a virtuálních jader .

Počet databází, které se dají umístit do hustých fondů, aniž by to způsobilo kolize prostředků a problémy s výkonem, závisí na počtu souběžně aktivních databází a na spotřebě prostředků uživatelskými úlohami v každé databázi. Toto číslo se může v průběhu času měnit při změně uživatelských úloh.

Pokud je navíc minimální počet virtuálních jader na databázi nebo minimální počet DTU na databázi nastavený na hodnotu větší než 0, bude maximální počet databází ve fondu implicitně omezený. Další informace naleznete v tématu Vlastnosti databáze pro databáze ve fondu virtuálních jader a vlastnosti databáze pro databáze ve fondu DTU.

Když dojde k kolizí prostředků v hustě zabaleném fondu, můžou si zákazníci vybrat jednu nebo více z následujících akcí, které ho zmírní:

  • Vylaďte úlohy dotazů, abyste snížili spotřebu prostředků nebo rozšířili spotřebu prostředků do více databází v průběhu času.
  • Snižte hustotu fondu přesunutím některých databází do jiného fondu nebo jejich vytvářením samostatných databází.
  • Vertikálně navyšte kapacitu fondu, abyste získali více prostředků.

Návrhy, jak implementovat poslední dvě akce, najdete v části Provozní doporučení dále v tomto článku. Snížení kolizí prostředků přináší výhody uživatelských úloh i interních procesů a umožňuje systému spolehlivě udržovat očekávanou úroveň služby.

Monitorování spotřeby prostředků

Aby se zabránilo snížení výkonu z důvodu kolize prostředků, měli by zákazníci, kteří používají zhuštěné elastické fondy, aktivně monitorovat spotřebu prostředků a provádět včasná opatření v případě, že zvýšení kolizí prostředků začne mít vliv na úlohy. Průběžné monitorování je důležité, protože využití prostředků ve fondu se mění v průběhu času kvůli změnám uživatelského zatížení, změnám datových svazků a distribuci, změnám hustoty fondu a změnám ve službě Azure SQL Database.

Azure SQL Database poskytuje několik metrik, které jsou relevantní pro tento typ monitorování. Překročení doporučené průměrné hodnoty pro každou metriku označuje kolize prostředků ve fondu a měla by být vyřešena pomocí jedné z akcí uvedených výše.

Pokud chcete odeslat upozornění, když využití prostředků fondu (procesor, vstupně-výstupní operace protokolu, vstupně-výstupní operace protokolu, pracovní procesy atd.) překročí prahovou hodnotu, zvažte vytvoření upozornění prostřednictvím webu Azure Portal nebo rutiny PowerShellu Add-AzMetricAlertRulev2. Při monitorování elastických fondů zvažte také vytvoření upozornění pro jednotlivé databáze ve fondu v případě potřeby ve vašem scénáři. Ukázkový scénář monitorování elastických fondů najdete v tématu Monitorování a správa výkonu služby Azure SQL Database v aplikaci SaaS s více tenanty.

Název metriky Popis Doporučená průměrná hodnota
avg_instance_cpu_percent Využití procesoru procesu SQL přidruženého k elastickému fondu měřené základním operačním systémem K dispozici v zobrazení sys.dm_db_resource_stats v každé databázi a v zobrazení sys.elastic_pool_resource_stats v master databázi. Tato metrika se také vygeneruje do služby Azure Monitor, kde je pojmenovanásql_instance_cpu_percent, a dá se zobrazit na webu Azure Portal. Tato hodnota je stejná pro každou databázi ve stejném elastickém fondu. Pod 70 %. Občasné krátké špičky až 90 % mohou být přijatelné.
max_worker_percent Využití pracovních vláken Poskytuje se pro každou databázi ve fondu i pro samotný fond. Existuje různá omezení počtu pracovních vláken na úrovni databáze a na úrovni fondu, proto se doporučuje monitorování této metriky na obou úrovních. K dispozici v zobrazení sys.dm_db_resource_stats v každé databázi a v zobrazení sys.elastic_pool_resource_stats v master databázi. Tato metrika se také vygeneruje do služby Azure Monitor, kde je pojmenovanáworkers_percent, a dá se zobrazit na webu Azure Portal. Pod 80 %. Špičky až o 100 % způsobí selhání pokusů o připojení a dotazů.
avg_data_io_percent Využití vstupně-výstupních operací čtení a zápisu za sekundu za sekundu Poskytuje se pro každou databázi ve fondu i pro samotný fond. Počet IOPS na úrovni databáze a na úrovni fondu má různá omezení, proto se doporučuje monitorování této metriky na obou úrovních. K dispozici v zobrazení sys.dm_db_resource_stats v každé databázi a v zobrazení sys.elastic_pool_resource_stats v master databázi. Tato metrika se také vygeneruje do služby Azure Monitor, kde je pojmenovanáphysical_data_read_percent, a dá se zobrazit na webu Azure Portal. Pod 80 %. Občasné krátké špičky až 100 % mohou být přijatelné.
avg_log_write_percent Využití propustnosti pro vstupně-výstupní operace zápisu transakčního protokolu Poskytuje se pro každou databázi ve fondu i pro samotný fond. Na úrovni databáze existují různá omezení propustnosti protokolů a na úrovni fondu, proto se doporučuje monitorování této metriky na obou úrovních. K dispozici v zobrazení sys.dm_db_resource_stats v každé databázi a v zobrazení sys.elastic_pool_resource_stats v master databázi. Tato metrika se také vygeneruje do služby Azure Monitor, kde je pojmenovanálog_write_percent, a dá se zobrazit na webu Azure Portal. Pokud je tato metrika blízko 100 %, všechny změny databáze (INSERT, UPDATE, DELETE, MERGE příkazy, SELECT ... INTO, BULK INSERT atd.) bude pomalejší. Pod 90 %. Občasné krátké špičky až 100 % mohou být přijatelné.
oom_per_second Rychlost chyb nedostatku paměti (OOM) v elastickém fondu, což je indikátor zatížení paměti. K dispozici v zobrazení sys.dm_resource_governor_resource_pools_history_ex . Podívejte se na příklady ukázkového dotazu pro výpočet této metriky. Další informace najdete v tématu Omezení prostředků pro elastické fondy využívající jednotky DTU nebo elastické fondy s využitím virtuálních jader a řešení chyb kvůli nedostatku paměti ve službě Azure SQL Database. Pokud dojde k chybám s nedostatkem paměti, zkontrolujte sys.dm_os_out_of_memory_events. 0
avg_storage_percent Celkový prostor úložiště používaný daty ve všech databázích v rámci elastického fondu Nezahrnuje prázdné místo v databázových souborech. K dispozici v zobrazení sys.elastic_pool_resource_stats v master databázi. Tato metrika se také vygeneruje do služby Azure Monitor, kde je pojmenovanástorage_percent, a dá se zobrazit na webu Azure Portal. Pod 80 %. Může přistupovat k 100 % fondů bez růstu dat.
avg_allocated_storage_percent Celkový prostor úložiště používaný soubory databáze v úložišti ve všech databázích v rámci elastického fondu. Obsahuje prázdné místo v databázových souborech. K dispozici v zobrazení sys.elastic_pool_resource_stats v master databázi. Tato metrika se také vygeneruje do služby Azure Monitor, kde je pojmenovanáallocated_data_storage_percent, a dá se zobrazit na webu Azure Portal. Pod 90 %. Může přistupovat k 100 % fondů bez růstu dat.
tempdb_log_used_percent Využití prostoru transakčního tempdb protokolu v databázi I když dočasné objekty vytvořené v jedné databázi nejsou viditelné v jiných databázích ve stejném elastickém fondu, tempdb je sdíleným prostředkem pro všechny databáze ve stejném fondu. Dlouhotrvající nebo osamocené transakce spuštěné tempdb z jedné databáze ve fondu může spotřebovávat velkou část transakčního protokolu a způsobit selhání dotazů v jiných databázích ve stejném fondu. Odvozeno ze zobrazení sys.dm_db_log_space_usage a sys.database_files . Tato metrika se také vygeneruje do služby Azure Monitor a dá se zobrazit na webu Azure Portal. Podívejte se na příklady ukázkového dotazu, který vrátí aktuální hodnotu této metriky. Pod 50 %. Občasné špičky až 80 % jsou přijatelné.

Kromě těchto metrik poskytuje Azure SQL Database zobrazení, které vrací skutečné limity zásad správného řízení prostředků, a také další zobrazení, která vracejí statistiku využití prostředků na úrovni fondu prostředků a na úrovni skupiny úloh.

Název zobrazení Popis
sys.dm_user_db_resource_governance Vrátí skutečné nastavení konfigurace a kapacity používané mechanismy zásad správného řízení prostředků v aktuální databázi nebo elastickém fondu.
sys.dm_resource_governor_resource_pools Vrátí informace o aktuálním stavu fondu zdrojů, aktuální konfiguraci fondů zdrojů a kumulativní statistiku fondu zdrojů.
sys.dm_resource_governor_workload_groups Vrátí kumulativní statistiku skupiny úloh a aktuální konfiguraci skupiny úloh. Toto zobrazení je možné spojit s sys.dm_resource_governor_resource_pools ve pool_id sloupci a získat informace o fondu zdrojů.
sys.dm_resource_governor_resource_pools_history_ex Vrátí statistiku využití fondu zdrojů pro nedávnou historii na základě počtu dostupných snímků. Každý řádek představuje časový interval. Doba trvání intervalu je ve sloupci duration_ms . Sloupce delta_ vrací změnu v jednotlivých statistikách během intervalu.
sys.dm_resource_governor_workload_groups_history_ex Vrátí statistiku využití skupin úloh pro nedávnou historii na základě počtu dostupných snímků. Každý řádek představuje časový interval. Doba trvání intervalu je ve sloupci duration_ms . Sloupce delta_ vrací změnu v jednotlivých statistikách během intervalu.

Tip

Pokud chcete dotazovat tato a další zobrazení dynamické správy pomocí jiného objektu zabezpečení než správce serveru, přidejte tento objekt zabezpečení do ##MS_ServerStateReader## role serveru.

Tato zobrazení se dají použít k monitorování využití prostředků a řešení potíží s kolizemi prostředků téměř v reálném čase. Uživatelské úlohy na primárních a čitelných sekundárních replikách, včetně geografických replik, jsou klasifikovány do SloSharedPool1 fondu prostředků a UserPrimaryGroup.DBId[N] skupiny úloh, kde N je zkratka pro hodnotu ID databáze.

Kromě monitorování aktuálního využití prostředků můžou zákazníci, kteří používají zhuštěné fondy, udržovat historická data o využití prostředků v samostatném úložišti dat. Tato data je možné použít v prediktivní analýze k proaktivní správě využití prostředků na základě historických a sezónních trendů.

Provozní doporučení

Ponechte dostatečný prostor pro prostředky. Pokud dojde ke kolizím prostředků a snížení výkonu, může zmírnění rizik zahrnovat přesun některých databází z ovlivněného elastického fondu nebo vertikální navýšení kapacity fondu, jak je uvedeno výše. Tyto akce ale vyžadují dokončení dalších výpočetních prostředků. Konkrétně pro fondy Premium a Pro důležité obchodní informace tyto akce vyžadují přenos všech dat pro přesunuté databáze nebo pro všechny databáze v elastickém fondu, pokud je fond vertikálně navýšit. Přenos dat je dlouhotrvající operace náročná na prostředky. Pokud je fond již pod vysokým tlakem na prostředky, samotná operace zmírnění sníží výkon ještě více. V extrémních případech nemusí být možné vyřešit kolize prostředků prostřednictvím přesunu databáze nebo vertikálního navýšení kapacity fondu, protože požadované prostředky nejsou k dispozici. V takovém případě může být jediným řešením dočasné snížení zatížení dotazů v ovlivněném elastickém fondu.

Zákazníci, kteří používají zhuštěné fondy, by měli pečlivě monitorovat trendy využití prostředků, jak je popsáno výše, a podniknout kroky pro zmírnění, zatímco metriky zůstanou v doporučených rozsazích a v elastickém fondu stále existují dostatečné prostředky.

Využití prostředků závisí na několika faktorech, které se v průběhu času mění pro každou databázi a každý elastický fond. Dosažení optimálního poměru ceny a výkonu v hustých fondech vyžaduje nepřetržité monitorování a vyrovnávání, které přesouvá databáze z více využívaných fondů do méně využívaných fondů a vytváří nové fondy podle potřeby pro zajištění zvýšené zátěže.

Poznámka:

U elastických fondů DTU není metrika eDTU na úrovni fondu max ani suma využití jednotlivých databází. Odvozuje se z využití různých metrik na úrovni fondu. Limity prostředků na úrovni fondu můžou být vyšší než limity na úrovni jednotlivých databází, takže se může stát, že jedna databáze dosáhne limitu určitého prostředku (procesor, vstupně-výstupní operace dat, vstupně-výstupní operace protokolů atd.), i když sestava eDTU pro fond značí, že nedošlo k dosažení žádného limitu.

Nepřesouvejte "horké" databáze. Pokud kolize prostředků na úrovni fondu způsobuje především malý počet vysoce využívaných databází, může být lákavé přesunout tyto databáze do méně využívaného fondu nebo je nastavit jako samostatné databáze. Pokud však databáze zůstává vysoce využívaná, nedoporučuje se, protože operace přesunu bude dále snižovat výkon, a to jak pro přesun databáze, tak pro celý fond. Místo toho buď počkejte na snížení vysokého využití, nebo přesuňte méně využívané databáze místo toho, abyste snížili tlak na prostředky na úrovni fondu. Přesun databází s velmi nízkým využitím však v tomto případě neposkytuje žádnou výhodu, protože nijak podstatně nezmenšuje využití prostředků na úrovni fondu.

Vytvořte nové databáze ve fondu karantény. Ve scénářích, kdy se nové databáze vytvářejí často, například aplikace využívající model tenanta na databázi, hrozí riziko, že nová databáze umístěná do existujícího elastického fondu neočekávaně spotřebuje významné prostředky a ovlivní jiné databáze a interní procesy ve fondu. Pokud chcete toto riziko zmírnit, vytvořte samostatný fond karantény s ample přidělením prostředků. Tento fond použijte pro nové databáze s dosud neznámými vzory spotřeby prostředků. Jakmile databáze zůstane v tomto fondu pro obchodní cyklus, například týden nebo měsíc, a jeho spotřeba prostředků je známá, je možné ji přesunout do fondu s dostatečnou kapacitou, aby vyhovovala tomuto dalšímu využití zdrojů.

Monitorujte využitý i přidělený prostor. Pokud přidělený prostor fondu (celková velikost všech databázových souborů v úložišti pro všechny databáze ve fondu) dosáhne maximální velikosti fondu, může dojít k chybám mimo mezeru. Pokud jsou přidělené trendy prostoru vysoké a je na cestě dosáhnout maximální velikosti fondu, zahrnují možnosti omezení rizik:

  • Přesunutí některých databází z fondu za účelem snížení celkového přiděleného prostoru
  • Zmenšení databázových souborů za účelem zmenšení prázdného přiděleného místa v souborech
  • Vertikální navýšení kapacity fondu na cíl služby s větší maximální velikostí fondu

Pokud je využitý prostor fondu (celková velikost dat ve všech databázích ve fondu, nezahrnuje prázdné místo v souborech), trendy jsou vysoké a jsou na cestě k dosažení maximální velikosti fondu, mezi možnosti omezení rizik patří:

  • Přesunutí některých databází z fondu za účelem snížení celkového využitého místa
  • Přesunutí (archivace) dat mimo databázi nebo odstranění už nepotřebných dat
  • Implementace komprese dat
  • Vertikální navýšení kapacity fondu na cíl služby s větší maximální velikostí fondu

Vyhněte se příliš hustým serverům. Azure SQL Database podporuje až 5 000 databází na server. Zákazníci, kteří používají elastické fondy s tisíci databází, můžou zvážit umístění více elastických fondů na jeden server s celkovým počtem databází až do podporovaného limitu. Servery s mnoha tisíci databází ale vytvářejí provozní výzvy. Operace, které vyžadují výčet všech databází na serveru, například zobrazení databází na portálu, budou pomalejší. Provozní chyby, jako je nesprávná úprava přihlášení na úrovni serveru nebo pravidla brány firewall, ovlivní větší počet databází. Náhodné odstranění serveru bude vyžadovat pomoc od podpora Microsoftu k obnovení databází na odstraněném serveru a způsobí delší výpadek pro všechny ovlivněné databáze.

Omezte počet databází na server na nižší počet, než je maximální počet podporovaných. V mnoha scénářích je optimální využití až 1 000–2000 databází na server. Pokud chcete snížit pravděpodobnost náhodného odstranění serveru, umístěte zámek odstranění na server nebo na jeho skupinu prostředků.

Příklady

Zobrazení nastavení kapacity jednotlivých databází

sys.dm_user_db_resource_governance Zobrazení dynamické správy slouží k zobrazení skutečné konfigurace a nastavení kapacity používané zásadami správného řízení prostředků v aktuální databázi nebo elastickém fondu. Další informace najdete v tématu sys.dm_user_db_resource_governance.

Spusťte tento dotaz v libovolné databázi v elastickém fondu. Všechny databáze ve fondu mají stejné nastavení zásad správného řízení prostředků.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

Monitorování celkové spotřeby prostředků elastického fondu

sys.elastic_pool_resource_stats Pomocí zobrazení systémového katalogu můžete monitorovat spotřebu prostředků celého fondu. Další informace najdete v tématu sys.elastic_pool_resource_stats.

Tento ukázkový dotaz pro zobrazení posledních 10 minut by se měl spustit v master databázi logického serveru Azure SQL obsahujícího požadovaný elastický fond.

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

Monitorování spotřeby jednotlivých databázových prostředků

sys.dm_db_resource_stats Pomocí zobrazení dynamické správy můžete monitorovat spotřebu prostředků jednotlivých databází. Další informace najdete v tématu sys.dm_db_resource_stats. Jeden řádek existuje každých 15 sekund, i když neexistuje žádná aktivita. Historická data se uchovávají přibližně po dobu jedné hodiny.

Tento ukázkový dotaz pro zobrazení posledních 10 minut dat by se měl spustit v požadované databázi.

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

Pokud chcete delší dobu uchovávání s menší frekvencí, zvažte následující dotaz na sys.resource_statsspuštění v master databázi logického serveru Azure SQL. Další informace najdete v tématu sys.resource_stats (Azure SQL Database). Jeden řádek existuje každých pět minut a historická data se uchovávají po dobu dvou týdnů.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

Monitorování využití paměti

Tento dotaz vypočítá metriku oom_per_second pro každý fond zdrojů pro poslední historii na základě počtu dostupných snímků. Tento ukázkový dotaz pomáhá identifikovat nedávný průměrný počet neúspěšných přidělení paměti ve fondu. Tento dotaz lze spustit v libovolné databázi v elastickém fondu.

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

Monitorování tempdb využití prostoru protokolu

Tento dotaz vrátí aktuální hodnotu metriky, která zobrazuje relativní využití transakčního tempdb_log_used_percent tempdb protokolu vzhledem k maximální povolené velikosti. Tento dotaz lze spustit v libovolné databázi v elastickém fondu.

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

Další kroky