Předchozí

Další

Cvičení – škálování výkonu úlohy

Dokončeno

V tomto cvičení použijete problém, ke kterým jste narazili v prvním cvičení, a zvýšíte výkon škálováním více procesorů pro Azure SQL Database. Použijete databázi, kterou jste nasadili v předchozím cvičení.

Všechny skripty pro toto cvičení najdete ve složce 04-Performance\monitor_and_scale v úložišti GitHub, které jste naklonovali, nebo v souboru ZIP, který jste stáhli.

Škálování výkonu Azure SQL

Pokud chcete škálovat výkon při problému, který vypadá jako problém s kapacitou procesorů, měli byste se rozhodnout, jaké máte možnosti, a pak pokračovat ve škálování procesorů pomocí rozhraní poskytovaných pro Azure SQL.

1. Rozhodněte se, jak výkon škálovat. Vzhledem k tomu, že úloha je svázaná s procesorem, jedním ze způsobů, jak zvýšit výkon, je zvýšit kapacitu procesoru nebo rychlost. Aby uživatel SQL Serveru získal větší kapacitu procesorů, musel by přejít na jiný počítač nebo překonfigurovat virtuální počítač. V některých případech nemusí mít správce SQL Serveru oprávnění k provedení těchto změn škálování. Proces může trvat dlouho a dokonce vyžadovat migraci databáze.

   Pro Azure můžete použít ALTER DATABASEAzure CLI nebo Azure Portal ke zvýšení kapacity procesoru bez migrace databáze na straně uživatele.

2. Na portálu Azure Portal uvidíte možnosti, jak škálovat na více prostředků procesoru. V podokně Přehled vaší databáze vyberte cenovou úroveň pro aktuální nasazení. Cenová úroveň umožňuje změnit úroveň služby a počet virtuálních jader.

   

3. Tady uvidíte možnosti pro změnu nebo škálování výpočetních prostředků. U úrovně Pro obecné účely můžete snadno škálovat až na nějakých 8 virtuálních jader.

   

   Ke škálování úlohy můžete použít také jinou metodu.

4. Abyste v tomto cvičení uviděli správné rozdíly v sestavách, musíte nejdříve vyprázdnit úložiště dotazů. V aplikaci SQL Server Management Studio (SSMS) vyberte databázi AdventureWorks a použijte nabídku Soubor>otevřít>soubor. Otevřete skript flushhquerystore.sql v aplikaci SSMS v kontextu databáze AdventureWorks. V okně editoru dotazů by se měl zobrazit text podobný následujícímu:

   EXEC sp_query_store_flush_db;
   

   Vyberte Spustit a spusťte tuto dávku T-SQL.

   Poznámka:

   Spuštění předchozího dotazu vyprázdní část úložiště dotazů na disk v paměti.

5. V SSMS otevřete skript get_service_objective.sql. V okně editoru dotazů by se měl zobrazit text podobný následujícímu:

   SELECT database_name,slo_name,cpu_limit,max_db_memory, max_db_max_size_in_mb, primary_max_log_rate,primary_group_max_io, volume_local_iops,volume_pfs_iops
   FROM sys.dm_user_db_resource_governance;
   GO
   SELECT DATABASEPROPERTYEX('AdventureWorks', 'ServiceObjective');
   GO
   

   Toto je způsob, jak pomocí T-SQL zjistit vaši úroveň služby. Cenová úroveň neboli úroveň služby se také označuje jako cíl služby. Vyberte Spustit a spusťte dávky T-SQL.

   Pro aktuální nasazení Azure SQL Database by výsledky měly vypadat jako na následujícím obrázku:

   

   Všimněte si termínu slo_name použitého pro cíl služby. slo znamená service level objective (cíl úrovně služby).

   Různé slo_name hodnoty nejsou zdokumentovány, ale můžete vidět z řetězcové hodnoty, že tato databáze používá úroveň služby pro obecné účely se dvěma virtuálními jádry:

   Poznámka:

   Při úrovni služby Pro důležité obchodní informace by řetězec měl podobu SQLDB_OP_....

   Když si zobrazíte dokumentaci k příkazu ALTER DATABASE, všimněte si toho, že můžete vybrat cílové nasazení SQL Serveru a získat tak správné možnosti syntaxe. Výběrem možnosti SQL Database – jednoúčelová databáze/elastický fond zobrazíte možnosti pro Azure SQL Database. Ke shodě s výpočetním škálováním, které jste našli na portálu, potřebujete cíl 'GP_Gen5_8'služby .

6. Upravte cíl služby pro databázi, abyste škálovali na více procesorů. Otevřete skript modify_service_objective.sql v SSMS a spusťte dávku T-SQL. V okně editoru dotazů by se měl zobrazit text podobný následujícímu:

   ALTER DATABASE AdventureWorks MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
   

   Tento příkaz se vrátí zpět okamžitě, ale škálování výpočetních prostředků probíhá na pozadí. Takto malé škálování by mělo trvat méně než minutu a po krátkou dobu bude databáze offline, aby se změna projevila. Průběh této aktivity škálování můžete monitorovat pomocí portálu Azure Portal.

   

7. V Průzkumníku objektů klikněte ve složce Systémové databáze pravým tlačítkem na hlavní databázi a vyberte Nový dotaz. V okně editoru dotazů SSMS spusťte tento dotaz:

   SELECT * FROM sys.dm_operation_status;
   

   Je to další způsob, jak monitorovat průběh změny cíle služby pro Azure SQL Database. Toto zobrazení dynamické správy ukáže historii změn v databázi při změně cíle služby pomocí příkazu ALTER DATABASE. Zobrazuje aktivní průběh změny.

   Tady je příklad výstupu tohoto zobrazení dynamické správy v tabulkovém formátu po spuštění výše uvedeného příkazu ALTER DATABASE:

   Item	Hodnota
   session_activity_id	97F9474C-0334-4FC5-BFD5-337CDD1F9A21
   resource_type	0
   resource_type_desc	Databáze
   major_resource_id	AdventureWorks
   minor_resource_id
   operation	ALTER DATABASE
   state	0
   state_desc	IN_PROGRESS
   percent_complete	0
   error_code	0
   error_desc
   error_severity	0
   error_state	0
   start_time	[datum a čas]
   last_modify_time	[datum a čas]

   Během provádění změny cíle služby jsou vůči databázi povolené dotazy, a to až do chvíle, kdy se implementuje konečná změna. Aplikace se proto nemůžou připojovat jen po velmi krátkou dobu. U spravované instance Azure SQL povoluje změna úrovně dotazy a připojení, ale brání všem databázovým operacím, jako je například vytvoření nových databází. V těchto případech se zobrazí následující chybová zpráva: Operaci nelze dokončit, protože probíhá změna úrovně služby pro spravovanou instanci [server]. Vyčkejte, než se operace dokončí, a zkuste to znovu.“

8. Po dokončení použijte předchozí dotazy uvedené z get_service_objective.sql v SSMS k ověření, že se projevil nový cíl služby nebo úroveň služby 8 virtuálních jader.

Spuštění úlohy po škálování

Teď, když má databáze větší kapacitu procesorů, můžeme spustit úlohu z předchozího cvičení, abychom zjistili, jestli se zlepší výkon.

1. Teď, když je škálování hotové, ověřte, jestli je úloha rychlejší a jestli se zmenšila čekání na prostředky procesoru. Znovu spusťte úlohu pomocí příkazu sqlworkload.cmd , který jste spustili v předchozím cvičení.

2. Pomocí SSMS spusťte stejný dotaz z prvního cvičení tohoto modulu ze skriptu dmdbresourcestats.sql, abyste mohli sledovat výsledky:

   SELECT * FROM sys.dm_db_resource_stats;
   

   Měli byste vidět, že průměrné využití prostředků procesoru se snížilo z téměř 100% využití v předchozím cvičení. sys.dm_db_resource_stats Za normálních okolností se zobrazuje jedna hodina aktivity. Změna velikosti databáze způsobí sys.dm_db_resource_stats resetování.

3. Pomocí SSMS spusťte stejný dotaz z prvního cvičení tohoto modulu ze skriptu dmexecrequests.sql, abyste mohli sledovat výsledky:

   SELECT er.session_id, er.status, er.command, er.wait_type, er.last_wait_type, er.wait_resource, er.wait_time
   FROM sys.dm_exec_requests er
   INNER JOIN sys.dm_exec_sessions es
   ON er.session_id = es.session_id
   AND es.is_user_process = 1;
   

   Uvidíte, že existuje více dotazů se stavem RUNNING. To znamená, že pracovní procesy mají k provádění dotazů větší kapacitu procesorů.

4. Sledujte novou dobu trvání úlohy. Doba trvání úlohy z sqlworkload.cmd by teď měla být mnohem kratší – a měla by být přibližně 25–30 sekund.

Sledování sestav z Úložiště dotazů

Pojďme se podívat na stejné sestavy z Úložiště dotazů jako v předchozím cvičení.

1. Pomocí stejných technik jako v prvním cvičení tohoto modulu se v SSMS podívejte na sestavu Top Resource Consuming Queries (Dotazy nejvíce využívající prostředky):

   

   Zobrazí se dva dotazy (query_id). Jedná se o stejné dotazy jako v prvním cvičení, ale v úložišti dotazů se zobrazí s jinými hodnotamiquery_id, protože operace škálování vyžadovala restartování a dotaz se musel znovu zkompilovat. V sestavě vidíte, že celková i průměrná doba trvání je výrazně menší.

2. Podívejte se také na sestavu Statistika čekání dotazu a vyberte panel čekání procesoru. Uvidíte, že průměrná doba čekání pro dotaz je menší a tvoří menší procento celkové doby trvání. Signalizuje to, že procesor už není tak kritickým bodem prostředků, jako když databáze měla menší počet virtuálních jader:

   

3. Všechny sestavy a okna editoru dotazů můžete zavřít. Nechte SSMS připojené, protože ho budete potřebovat v dalším cvičení.

Sledování změn pomocí Metrik Azure

1. Přejděte do databáze AdventureWorks na webu Azure Portal a znovu se podívejte na kartu Monitorování v podokně Přehled pro využití výpočetních prostředků:

   

   Všimněte si, že doba trvání vysokého využití procesorů je kratší, což znamená celkový pokles prostředků procesoru potřebných k provádění úlohy.

2. Tento graf může být trochu zavádějící. V nabídce Monitorování použijte metriky a pak nastavte metriku na limit procesoru. Graf porovnání procesoru vypadá podobně jako následující graf:

   

Tip

Pokud budete nadále přidávat virtuální jádra pro tuto databázi, můžete zvýšit výkon až na mezní hodnotu, při které všechny dotazy budou mít dostatek prostředků procesoru. Neznamená to, že by počet virtuálních jader musel odpovídat počtu souběžných uživatelů z vaší úlohy. Kromě toho můžete cenovou úroveň změnit tak, aby místo zřízeného používala bezserverovou výpočetní úroveň. Dosáhnete tak více automaticky škálovaného přístupu k úloze. Pokud jste například pro tuto úlohu zvolili minimální hodnotu virtuálního jádra 2 a maximální hodnotu virtuálního jádra 8, tato úloha by se okamžitě škálovala na 8 virtuálních jader.

V dalším cvičení zjistíte problém s výkonem a vyřešíte ho použitím osvědčených postupů pro výkon aplikace.

Pokračovat