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

Článek
10/14/2021
12 min ke čtení

PLATÍ PRO: Azure SQL Database

Azure SQL Database elastické fondy jsou cenově výhodné řešení pro správu mnoha databází s různými využitími 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ě, tempdb na předpokladu, že pouze podmnožina databází ve fondu bude v daném okamžiku používat výpočetní prostředky. Tento předpoklad umožňuje, aby elastické fondy byly nákladově efektivní. Místo placení všech prostředků, které by mohla každá databáze potenciálně potřebovat, můžou zákazníci platit mnohem menší sadu prostředků, která se sdílí 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ě prostudoval využití prostředků, aby se minimalizoval efekt "vysokého" souseda, kde databáze s vysokou spotřebou prostředků ovlivňuje další databáze ve stejném elastickém fondu. Systém zároveň musí poskytovat dostatek prostředků 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., aby fungovala spolehlivě.

Azure SQL Database dosahuje těchto cílů pomocí více mechanismů zásad správného řízení prostředků, včetně Windows objektů úloh pro řízení prostředků na úrovni procesu, Windows souborového serveru Správce prostředků (správce prostředků pro správu kvót úložiště) a upravené a rozšířené verze SQL Server správce zdrojů k implementaci zásady správného řízení prostředků v rámci SQL Database.

Primární cíl pro elastické fondy je finančně efektivní. Z tohoto důvodu systém úmyslně umožňuje zákazníkům vytvářet husté fondy, což je fondy s počtem přístupů k databázím nebo s povoleným maximálním počtem, ale s mírným přidělením výpočetních prostředků. Ze stejného důvodu systém nerezervuje všechny potenciálně potřebné prostředky pro své interní procesy, ale umožňuje sdílení prostředků mezi interními procesy a úlohami uživatelů.

Tento přístup zákazníkům umožňuje využít husté elastické fondy k zajištění dostatečného výkonu a nákladů na velké náklady. Pokud je ale zatížení s mnoha databázemi v hustém fondu dostatečně náročné, může se spor na prostředky významně zvýšit. Kolizí 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é zvyšovat počet databází ve fondu až do maximálních hodnot dokumentovaných pro DTU a elastické fondy Vcore .

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

Pokud je navíc nastavení min virtuální jádra na databázi nebo min DTU na databázi nastaveno na hodnotu větší než 0, bude maximální počet databází ve fondu implicitně omezený. Další informace najdete v tématu Vlastnosti databáze pro Vcore databáze a Vlastnosti databáze pro fondy databází DTU.

Pokud se spory prostředků vyskytují v hustě zkomprimovaném fondu, můžou si zákazníci vybrat jednu nebo více následujících akcí, které ji budou zmírnit:

Optimalizujte úlohy dotazů, abyste snížili spotřebu prostředků, nebo rozšíříte spotřebu prostředků napříč více databázemi v průběhu času.
Zmenšení hustoty fondu přesunutím některých databází do jiného fondu nebo jejich samostatnými databázemi.
Navýšení kapacity fondu za účelem získání dalších 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áší úlohy uživatelů i interní procesy 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ů, Zákazníci využívající husté elastické fondy by měli proaktivně monitorovat spotřebu prostředků a provádět včasné akce, pokud se začne zvyšovat dopad prostředků na úlohy. průběžné monitorování je důležité, protože využití prostředků ve fondu se v průběhu času mění podle změn v uživatelských úlohách, změnách v datových svazcích a distribuci, změn v hustotě fondu a změnách 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ělo by se řešit pomocí jedné z výše zmíněných akcí.

Název metriky	Description	Doporučená průměrná hodnota
`avg_instance_cpu_percent`	využití CPU v procesu SQL přidruženého k elastickému fondu, jak je měřené v podkladovém operačním systému. 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é generuje do Azure Monitor, kde se nazývá `sqlserver_process_core_percent` , a je možné ji zobrazit v Azure Portal. Tato hodnota je stejná pro každou databázi ve stejném elastickém fondu.	Pod 70%. Může být přijatelné příležitostné krátké špičky až do 90%.
`max_worker_percent`	Využití pracovního vlákna . K dispozici pro každou databázi ve fondu a také pro samotný fond. Existují různá omezení počtu pracovních vláken na úrovni databáze a na úrovni fondu, proto je vhodné monitorovat tuto metriku 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é generuje do Azure Monitor, kde se nazývá `workers_percent` , a je možné ji zobrazit v Azure Portal.	Pod 80%. Špičky až do 100% způsobí, že se pokusy o připojení a dotazy selžou.
`avg_data_io_percent`	Využití IOPS pro čtení a zápis fyzické v/v. K dispozici pro každou databázi ve fondu a také pro samotný fond. Existují různá omezení počtu IOPS na úrovni databáze a na úrovni fondu, proto je vhodné monitorovat tuto metriku 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é generuje do Azure Monitor, kde se nazývá `physical_data_read_percent` , a je možné ji zobrazit v Azure Portal.	Pod 80%. Může být přijatelné příležitostné krátké špičky až do 100%.
`avg_log_write_percent`	Využití propustnosti pro zápis protokolu transakcí v/v. K dispozici pro každou databázi ve fondu a také pro samotný fond. Propustnost protokolu na úrovni databáze a na úrovni fondu jsou 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é generuje do Azure Monitor, kde se nazývá `log_write_percent` , a je možné ji zobrazit v Azure Portal. Pokud je tato metrika blízko až 100%, všechny úpravy databáze (příkazy INSERT, UPDATE, DELETE, MERGE, SELECT... DO, BULK INSERT atd.) bude pomalejší.	Pod 90%. Může být přijatelné příležitostné krátké špičky až do 100%.
`oom_per_second`	Frekvence chyb v nedostatku paměti (OOM) v elastickém fondu, což je indikátor přetížení paměti. K dispozici v zobrazení Sys.dm_resource_governor_resource_pools_history_ex . Podívejte se na Příklady pro výpočet této metriky pomocí ukázkového dotazu.	0
`avg_storage_percent`	Celkové místo v úložišti využité daty ve všech databázích v elastickém fondu. Nezahrnuje prázdné místo v souborech databáze. K dispozici v zobrazení Sys.elastic_pool_resource_stats v `master` databázi. Tato metrika se také generuje do Azure Monitor, kde se nazývá `storage_percent` , a je možné ji zobrazit v Azure Portal.	Pod 80%. Může pro fondy bez nárůstu dat přistupovat 100%.
`avg_allocated_storage_percent`	Celkové místo v úložišti používané soubory databáze v úložišti ve všech databázích v elastickém fondu. Obsahuje prázdné místo v souborech databáze. K dispozici v zobrazení Sys.elastic_pool_resource_stats v `master` databázi. Tato metrika se také generuje do Azure Monitor, kde se nazývá `allocated_data_storage_percent` , a je možné ji zobrazit v Azure Portal.	Pod 90%. Může pro fondy bez nárůstu dat přistupovat 100%.
`tempdb_log_used_percent`	Využití místa protokolu transakcí v `tempdb` 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 `tempdb` spuštěná z jedné databáze ve fondu může spotřebovat velkou část transakčního protokolu a způsobit chyby dotazů v jiných databázích ve stejném fondu. Je odvozena z zobrazení Sys.dm_db_log_space_usage a Sys.database_files . Tato metrika se také generuje do Azure Monitor a je možné ji zobrazit v Azure Portal. Podívejte se na Příklady ukázkový dotaz, který vrátí aktuální hodnotu této metriky.	Pod 50%. Příležitostné špičky až do 80% jsou přijatelné.

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

Název zobrazení	Description
sys.dm_user_db_resource_governance	Vrátí vlastní 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 statistikách kumulativních fondů prostředků.
sys.dm_resource_governor_workload_groups	Vrátí souhrnné statistické údaje o skupině úloh a aktuální konfiguraci skupiny úloh. Toto zobrazení může být spojeno s sys.dm_resource_governor_resource_pools ve `pool_id` sloupci, aby bylo možné získat informace o fondu zdrojů.
sys.dm_resource_governor_resource_pools_history_ex	Vrátí statistiku využití fondu zdrojů za posledních 32 minut. Každý řádek představuje 20sekunový interval. Sloupce `delta_` v intervalu vrací změnu v jednotlivých statistikách.
sys.dm_resource_governor_workload_groups_history_ex	Vrátí statistiku využití skupiny úloh za posledních 32 minut. Každý řádek představuje 20sekunový interval. Sloupce `delta_` v intervalu vrací změnu v jednotlivých statistikách.

Tip

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

Tato zobrazení je možné použít k monitorování využití prostředků a řešení potíží s náporem prostředků 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, se klasifikují do fondu prostředků a skupiny úloh, kde představuje SloSharedPool1 UserPrimaryGroup.DBId[N] hodnotu ID N databáze.

Kromě monitorování aktuálního využití prostředků mohou zákazníci, kteří používají hustotu fondů, uchovávat historická data o využití prostředků v samostatném úložiště dat. Tato data je možné použít při 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čnou prostor pro prostředky. Pokud dojde ke náporu prostředků a snížení výkonu, omezení rizik může zahrnovat přesunutí některých databází z ovlivněného elastického fondu nebo navýšení kapacity fondu, jak je uvedeno výše. Tyto akce ale k dokončení vyžadují další výpočetní prostředky. Konkrétně pro fondy Premium a Pro důležité obchodní informace vyžadují tyto akce přenos všech dat pro přesouvané databáze nebo pro všechny databáze v elastickém fondu, pokud dojde ke škálování fondu. Přenos dat je dlouhotrcí operace, která je náročná na prostředky. Pokud je fond již pod vysokým náklady na prostředky, samotná operace zmírňující rizika ještě více snižuje výkon. V extrémních případech nemusí být možné vyřešit problémy s prostředky prostřednictvím přesunu databáze nebo škálování fondu nahoru, 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í hustotu fondů, by měli pečlivě monitorovat trendy využití prostředků, jak je popsáno výše, a provést zmírňující opatření, zatímco metriky zůstávají v doporučených rozsahech a v elastickém fondu je stále dostatek prostředků.

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 cena/výkon v hustotě fondů vyžaduje nepřetržité monitorování a vyvažování, které přesouvá databáze z více využíovaných fondů do méně využíovaných fondů, a vytváření nových fondů podle potřeby, aby se přizpůsobil zvýšenému zatížení.

Neposouhněte "horké" databáze. Pokud je ke šátku prostředků na úrovni fondu primárně způsobený malým počtem vysoce využíovaných databází, může být schůdné přesunout tyto databáze do méně využívatého fondu nebo je z nich udělat samostatné databáze. To však nedoporučujeme, když databáze zůstává vysoce využívala, protože operace přesunutí dále snižuje výkon, a to jak u přesouvané databáze, tak u celého fondu. Místo toho buď počkejte, než se vysoké využití zkrátí, nebo přesuňte méně využívované databáze, abyste na úrovni fondu zmírňují tlak na prostředky. Přesun databází s velmi nízkým využitím ale v tomto případě neposkytuje žádnou výhodu, protože nesnížuje využití prostředků na úrovni fondu.

Vytvořte nové databáze ve fondu karantény. Ve scénářích, kde se nové databáze vytvářejí často, například aplikace využívající model tenanta na databázi, existuje 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í další databáze a interní procesy ve fondu. Pokud chcete toto riziko zmírnit, vytvořte samostatný fond karantény s hojně přidělených prostředků. Tento fond použijte pro nové databáze s dosud neznámými vzory využití prostředků. Jakmile databáze v tomto fondu zůstala po dobu obchodního cyklu, jako je týden nebo měsíc, a je známá její spotřeba prostředků, je možné ji přesunout do fondu s dostatečnou kapacitou, aby se tomuto dodatečnému využití prostředků přizpůsobí.

Monitorujte využité i přidělené místo. Když přidělené místo ve 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 kvůli volnému prostoru. Pokud dochází k vysokému trendu přiděleného prostoru a je na dobré cestě k dosažení maximální velikosti fondu, mezi možnosti omezení rizik patří:

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

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

Přesunutím některých databází mimo fond snížíte celkové využité místo.
Přesun (archivace) dat mimo databázi nebo odstranění už nepotřebujete
Implementace komprese dat
Škálování fondu na cíl služby s větší maximální velikostí fondu

Vyhněte se příliš silný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í, mohou zvážit umístění několika 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í problémy. 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 jsou nesprávné úpravy přihlášení na úrovni serveru nebo pravidel brány firewall, ovlivní větší počet databází. Náhodné odstranění serveru bude vyžadovat pomoc od Podpora Microsoftu obnovení databází na odstraněném serveru a způsobí delší výpadek pro všechny ovlivněné databáze.

Doporučujeme omezit počet databází na server na nižší počet, než je podporované maximum. V mnoha scénářích je optimální použít až 1000 až 2 000 databází na server. Pokud chcete snížit pravděpodobnost náhodného odstranění serveru, umístěte na server nebo jeho skupinu prostředků zámek proti odstranění.

Příklady

Monitorování využití paměti

Tento dotaz vypočítá oom_per_second metriku pro každý fond zdrojů za posledních 32 minut. Tento dotaz je možné spustit v jakékoli 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 protokolů

Tento dotaz vrátí aktuální hodnotu metriky, která zobrazuje relativní využití transakčního protokolu vzhledem k tempdb_log_used_percent tempdb maximální povolené velikosti. Tento dotaz je možné spustit v jakékoli 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

Úvod do elastických fondů najdete v tématu Elastické fondyvám pomůžou spravovat a škálovat více databází v Azure SQL Database .
Informace o ladění úloh dotazů za účelem snížení využití prostředků najdete v tématu Monitorování a laděnía Monitorování a ladění výkonu.