Analýza výkonu vstupně-výstupních operací – SQL Server na virtuálních počítačích Azure

Applies to:SQL Server na virtuálním počítači Azure

V tomto článku se naučíte analyzovat výkon vstupně-výstupních operací pro SQL Server on Azure Virtual Machines (virtuální počítače), abyste zjistili problémy, které vedou k překročení limitů virtuálních počítačů a datových disků.

Přehled

I když vám různé nástroje pomáhají řešit problémy s výkonem SQL Server, je důležité, abyste to efektivně udělali na virtuálním počítači Azure, je důležité pochopit, co se děje na úrovni hostitele i na SQL Server instanci, kde může být často náročné korelovat metriky hostitele s SQL Server úlohami. SQL Server na virtuálních počítačích Azure usnadňují identifikaci problémů s výkonem vyplývajících z IOPS (vstupně-výstupní za sekundu) a omezování propustnosti způsobené překročením limitů virtuálních počítačů a datových disků.

Metriky výkonu, které ukazují problém a potenciální kroky k jeho vyřešení, jsou k dispozici na portálu Azure a dají se dotazovat pomocí Azure CLI.

Prostředek Storage vašich virtuálních počítačů SQL na portálu Azure vám pomůže:

Správa konfigurace úložiště
Identifikace omezování vstupně-výstupních operací
Vyhodnocení osvědčených postupů souvisejících s vstupně-výstupními operacemi v systému

Porozumění metrikám

Karta Analýza vstupně-výstupních operací spoléhá na metriky Azure k identifikaci latence disku a omezování vstupně-výstupních operací virtuálního počítače nebo disku. Azure Metriky se vzorkují každých 30 sekund a agregují se na minutu.

Systém monitoruje omezování výkonu a latenci disku. Očekává se určité omezování a bude ignorováno, pokud není také přítomna latence disku. Pokud je latence disku delší než 500 milisekund po sobě jdoucích 5 minut, systém:

Podrobnější informace o metrikách výkonu
Identifikuje omezený prostředek.
Poskytuje potenciální hlavní příčiny a kroky pro zmírnění rizik.

Následující tabulka vysvětluje Azure Metriky používané k identifikaci problematických problémů s omezováním:

Metrika Azure	Popis metriky	Problematický stav	Závěry omezování vstupu/výstupu
Latence disku (Preview)	Průměrná doba dokončení vstupně-výstupních operací datového disku během sledovaného období. Hodnoty jsou v milisekundách.	> 500 milisekund v po sobě jdoucím 5minutovém období	Existuje problém s latencí, který brání systému dále prošetřit potenciální omezování.
Procento spotřebovaných mezipaměťových IOPS ve virtuálním počítači	Procento vypočítané celkovým počtem vstupně-výstupních operací za sekundu nad limitem maximálního počtu vstupně-výstupních operací za sekundu virtuálního počítače v mezipaměti.	>= 95 % v po sobě jdoucím 5minutovém období	Dochází k omezování virtuálního počítače. Aplikace spuštěná na virtuálním počítači SQL plně využívá maximální kapacitu IOPS uloženou v mezipaměti dostupnou pro virtuální počítač – požadavky aplikace na úložiště překračují počet IOPS uložených v mezipaměti poskytovanou základní konfigurací úložiště virtuálního počítače.
Procento spotřebované šířky pásma v mezipaměti virtuálního počítače	Procento vypočítané dělením celkové propustnosti disku maximální propustností virtuálního počítače v mezipaměti.	>= 95 % v po sobě jdoucím 5minutovém období	Dochází k omezování virtuálního počítače. Aplikace spuštěná na virtuálním počítači SQL využívá maximální dostupnou šířku pásma disku uložené v mezipaměti pro přenos dat – požadavky na přenos dat aplikace překračují prostředky šířky pásma uložené v mezipaměti poskytované základní konfigurací úložiště virtuálního počítače.
Procento IOPS mimo mezipaměť využité virtuálním počítačem	Procento vypočítané na základě celkového počtu vstupně-výstupních operací za sekundu na virtuálním počítači, které byly dokončeny nad maximálním limitem IOPS pro virtuální počítač neuložený ve vyrovnávací paměti.	>= 95 % v po sobě jdoucím 5minutovém období	Dochází k omezování virtuálního počítače. Aplikace spuštěná na virtuálním počítači SQL využívá maximální dostupnou kapacitu IOPS bez mezipaměti dostupnou pro virtuální počítač – požadavky na úložiště aplikace překračují prostředky IOPS bez mezipaměti poskytované základní konfigurací úložiště virtuálního počítače.
Procento šířky pásma mimo mezipaměť využité virtuálním počítačem	Procento vypočítané jako poměr celkové propustnosti disku na virtuálním počítači k maximální zřízené propustnosti virtuálního počítače.	>= 95 % v po sobě jdoucím 5minutovém období	Dochází k omezování virtuálního počítače. Aplikace spuštěná na virtuálním počítači SQL využívá maximální povolenou šířku pásma disku bez mezipaměti pro přenos dat – požadavky na přenos dat aplikace překračují prostředky šířky pásma bez mezipaměti poskytované základní konfigurací úložiště virtuálního počítače.
Procento využitých IOPS datového disku	Procentuální hodnota vypočítaná jako poměr dokončených IOPS datového disku oproti zřízeným IOPS datového disku.	>= 95 % v po sobě jdoucím 5minutovém období	Probíhá omezování datového disku. Aplikace spuštěná na virtuálním počítači SQL dosáhne limitu IOPS zřízeného datového disku – požadavky aplikace na úložiště překračují možnosti výkonu zvolené konfigurace disku.
Procento využité šířky pásma datového disku	Procentuální podíl vypočítaný z propustnosti dokončeného datového disku vůči propustnosti přiděleného datového disku.	>= 95 % v po sobě jdoucím 5minutovém období	Probíhá omezování datového disku. Aplikace spuštěná na virtuálním počítači SQL dosáhne limitu IOPS zřízeného datového disku – požadavky aplikace na úložiště překračují možnosti výkonu zvolené konfigurace disku.

Zjištění analýzy vstupně-výstupních operací

Na základě analýzy metrik výkonu za posledních 24 hodin analýza vstupně-výstupních operací určuje, že existuje:

Bez škrcení
Omezování vstupně-výstupních operací na úrovni virtuálního počítače
Omezování vstupně-výstupních operací na úrovni disku

Žádný problém s omezováním I/O

Pokud dochází k potížím s výkonem, ale nemáte žádnou latenci disku, problém s výkonem není způsoben problémem s omezováním vstupně-výstupních operací. Budete muset prozkoumat další oblasti. Můžete použít kontrolní seznam osvědčených postupů pro SQL Server na virtuálních počítačích Azure k zajištění efektivní konfigurace systému nebo najít užitečné odkazy pro řešení potíží s výkonem SQL Serveru. Pokud povolíte posouzení osvědčených postupů pro SQL, zobrazí se úplný seznam doporučení pro váš virtuální počítač SQL Server.

Problém s omezováním vstupně-výstupních operací na úrovni virtuálního počítače

Azure Virtual Machines jsou cloudové výpočetní prostředky, které mají různé řady a velikosti pro různé úlohy, z nichž každá má různé možnosti a charakteristiky výkonu. Pro SQL Server úlohy obecně platí, že doporučená řada pro SQL Server úlohy jsou ty optimalizované pro paměť, například řady Ebdsv5, M a Mv2.

Velikost virtuálního počítače určuje počet virtuálních procesorů, paměti a úložiště dostupných pro SQL Server instanci. V porovnání s úložištěm je pro zákazníky poměrně snadné změnit velikost virtuálních počítačů a škálovat virtuální počítač nahoru a dolů na základě potřeb prostředků aplikace. Vzhledem k tomu, že na úrovni virtuálního počítače je možné omezovat vstupně-výstupní operace za sekundu a propustnost, vyberte v závislosti na potřebách výkonu a nákladech na zatížení odpovídající velikost virtuálního počítače.

Pokud migrujete na Azure, můžete použít posouzení připravenosti na migrace a analyzovat aktuální konfiguraci a využití SQL Server a navrhnout nejlepší velikost virtuálního počítače pro vaši úlohu v Azure.

Následující metriky Azure se používají k určení, zda je zátěž omezena, aby nedošlo k překročení limitů uvalených virtuálním počítačem:

Procento spotřebovaných mezipamětí IOPS u virtuálního počítače
Procento využité šířky pásma cache virtuálního počítače
Procento IOPS mimo mezipaměť využité virtuálním počítačem
Procento šířky pásma mimo mezipaměť spotřebované virtuálním počítačem

Zvažte následující klíčové body týkající se omezování virtuálních počítačů:

Změnou velikosti virtuálního počítače v rámci řady virtuálních počítačů můžete zvýšit paměť, virtuální jádra, propustnost a IOPS.
Velikost virtuálního počítače nemůžete zmenšit na úroveň, ve které počet datových disků překračuje limit maximálních datových disků pro cílovou velikost virtuálního počítače.
Je důležité určit model omezování. Například občasné špičky škrcení je možné vyřešit laděním zatížení, zatímco dlouhodobé špičky můžou značit, že podkladové úložiště není schopno zvládnout zatížení.

Problém s omezováním I/O na úrovni disku

Pro zákazníky virtuálních počítačů SQL je úložiště nejdůležitějším aspektem konfigurace pro optimalizovaný výkon, protože úprava úložiště je náročnější než změna velikosti virtuálního počítače. Například provedení jakýchkoli změn zvýšení IOPS nebo propustnosti disků SSD úrovně Premium vyžaduje vytvoření nového fondu úložiště. Proto je zásadní optimalizovat konfiguraci úložiště pro cenu i výkon během fáze plánování, abyste se vyhnuli problémům s výkonem po nasazení.

Následující metriky Azure se používají k určení, zda zatížení bylo omezeno z důvodu překročení limitů stanovených diskem:

Procento využití IOPS datového disku
Procento spotřebované šířky pásma datového disku Zvažte následující klíčové body týkající se omezování vstupně-výstupních operací na úrovni disku:
Datový disk je kritický pro výkon SQL Server. Doporučujeme umístit SQL Server data (.mdf) a soubory protokolu (.df) na datový disk.
Je-li k dispozici, povolte ukládání do mezipaměti pro čtení na úrovni datového disku.

Procento využití IOPS datového disku

Metrika IOPS využitého datového disku v procentech měří spotřebu IOPS na úrovni disku. Obecně platí, že vysoké potřeby IOPS jsou spojené s vysoce transakčními aplikacemi a úlohami založenými na OLTP.   Následující scénáře nebo podmínky můžou potenciálně překročit limity vstupně-výstupních operací za sekundu datového disku:

Vysoká úloha transakcí (IOPS): Pokud aplikace zpracovává velký objem databázových transakcí, které zahrnují časté operace čtení a zápisu, může rychle spotřebovat přidělené IOPS. 
Neefektivní dotazy: Špatně optimalizované dotazy SQL nebo operace načítání dat mohou vést k nadměrné vstupně-výstupní aktivitě, která spotřebovává více I/O operací, než se očekávalo. 
Souběžní uživatelé: Pokud k databázi současně přistupuje více uživatelů nebo relací a generuje vstupně-výstupní požadavky, může kumulativní účinek způsobit dosažení limitu IOPS. 
Zdroje informací: Pokud je základní fyzická infrastruktura silně sdílená s jinými tenanty nebo úlohami, může to mít vliv na dostupné IOPS pro váš virtuální počítač. 
Dočasné špičky: Dočasné špičky v úlohách, jako je dávkové zpracování nebo migrace dat, můžou vést k náhlému nárůstu počtu vstupně-výstupních operací, které překračují přidělený počet vstupně-výstupních operací za sekundu. 
Malá velikost disku: Pokud je velikost zřízeného datového disku relativně malá, může být kapacita IOPS omezená. Jednotlivé menší disky mají nižší limity pro IOPS, a pokud požadavky aplikace překročí tento limit, procento využití IOPS datového disku dosáhne 100 %. 
Nedostatečný typ disku: Volba typu disku s nižším výkonem (například HDD úrovně Standard) pro aplikaci náročné na vstupně-výstupní operace může vést k omezením IOPS. 
Neoptimalizovaná velikost prokládání disků: Pokud konfigurace úložiště není optimalizovaná pro úlohu, může to vést k neoptimálnímu výkonu IOPS.

Zvažte následující kroky, abyste se vyhnuli překročení limitu IOPS datového disku:

Optimalizujte dotazy SQL a návrh databáze, abyste minimalizovali zbytečné vstupně-výstupní operace. 
Zvolte odpovídající typ disku (SSD úrovně Standard nebo SSD úrovně Premium), který odpovídá požadavkům vaší aplikace na IOPS. 
Pokud chcete zvýšit dostupnou kapacitu IOPS, použijte větší disky. 
Distribuce vstupně-výstupních operací mezi více datových disků pomocí konfigurací RAID

Procento spotřebované šířky pásma datového disku

Metrika Data Disk Bandwidth Consumed Percentage Azure měří využití šířky pásma na úrovni disku. Obecně platí, že požadavky na vysokou propustnost jsou spojené s datovými sklady, datovým tržištěm, generováním sestav, ETL a dalšími úlohami analýzy dat.

Následující scénáře nebo podmínky můžou potenciálně překročit limity šířky pásma datového disku:

Velké přenosy dat: Časté rozsáhlé přenosy dat aplikací mezi diskem a databází SQL můžou rychle využívat dostupnou šířku pásma datového disku. 
Hromadné načítání dat: Aktivity přenosu disků přidružené k hromadným vkládáním, aktualizacím nebo importům dat můžou vést k vysoké spotřebě šířky pásma. 
Datové sklady nebo analýzy: Aplikace, které zahrnují velké datové sklady, zpracování analýz nebo generování sestav, můžou generovat značné přesuny dat, což může způsobit překročení limitů šířky pásma.
Technologie vysoké redundance dat / replikace: Kopírování dat spojené s využitím replikace založené na disku, zrcadlení dat nebo jiných mechanismů redundance může přispět k nasycení šířky pásma. 
Zálohování a obnovení dat: Časté zálohování dat, snímky nebo procesy obnovení můžou spotřebovávat významnou šířku pásma datového disku. 
Paralelní spouštění dotazů: Paralelní dotazy, které zahrnují rozsáhlé prohledávání dat nebo spojení, můžou vést k podstatnému přesunu dat, který vede k využití šířky pásma. 
Zvýšený síťový provoz: Vysoká síťová aktivita, jako jsou přenosy dat mezi virtuálním počítačem a dalšími prostředky, můžou nepřímo ovlivnit dostupnost šířky pásma datového disku. 
Nedostatečný typ disku: Volba typu disku s nižším výkonem pro aplikaci s vysokými požadavky na přenos dat může vést k překročení limitu šířky pásma. 
Souběžné operace náročné na data: Kombinovaný účinek několika souběžných procesů nebo relací přistupujících k datům na stejném disku a přenos dat může vést k dosažení limitu šířky pásma. 
Neoptimalizované dotazy nebo procesy ETL: Špatně optimalizované dotazy SQL nebo procesy extrakce, transformace, načítání (ETL) můžou vést k nadměrnému přesunu dat, což vede k nadměrné spotřebě šířky pásma.

Zvažte následující kroky, abyste se vyhnuli překročení limitu šířky pásma datového disku:

Optimalizujte operace přenosu dat, abyste minimalizovali zbytečný přesun dat. 
Zvažte použití typů disků s vyšším výkonem, které nabízejí větší kapacitu šířky pásma, například SSD úrovně Premium nebo SSD úrovně Premium v2.
Rozdělte data mezi více disků pomocí technik, jako je partitioning nebo sharding.
Optimalizujte a paralelizujte dotazy a zpracování dat, abyste snížili přesun dat.
Pomocí mechanismů komprese a efektivního úložiště dat snižte objem přenášených dat.
Podle potřeby monitorujte metriky výkonu a vertikálně navyšujte kapacitu konfigurací úložiště. Ssd úrovně Premium v2 umožňuje zákazníkům škálovat své IOPS a propustnost podle potřeby na vyžádání.
Je důležité pravidelně monitorovat a analyzovat metriky výkonu, abyste identifikovali příčinu omezení IOPS a podnikli příslušné akce pro optimalizaci výkonu úložiště pro váš virtuální počítač SQL.

Doporučení

Pravidelné monitorování metrik výkonu, ladění operací přenosu dat a optimalizace konfigurací disků zajišťuje, že výkon datového disku pro virtuální počítač SQL zůstane optimální bez překročení limitů.

Latence bez škrcení

Latence bez omezování znamená zpoždění přístupu k datům nebo zpracování, ke kterým dochází i v případě, že systém úložiště nedosahuje maximálních limitů vstupně-výstupních operací za sekundu nebo propustnosti. Latence ve virtuálních počítačích Azure může vzniknout z různých zdrojů, včetně I/O stacku operačního systému, zpracování SQL Serveru, režie sítě nebo plánování hypervisoru. Identifikace příčiny latence je důležitá k optimalizaci výkonu SQL Server na virtuálních počítačích Azure.

Pokud je zjištěna latence bez omezování rychlosti, zobrazí se na kartě Analýza I/O v podokně Úložiště následující upozornění: Warning: High disk latency detected without throttling

Následující seznam uvádí potenciální příčiny latence bez omezení rychlosti.

Vysoké využití procesoru: Vysoké zatížení procesoru může zpomalit vstupně-výstupní operace, protože procesor je zaneprázdněn úlohami, jako je šifrování, komprese nebo spouštění dotazů. To platí hlavně u virtuálních počítačů s menším počtem jader. Pokud nejsou k dispozici cykly procesoru, vstupně-výstupní požadavky můžou čekat delší dobu na zpracování, což zvyšuje latenci i v případě, že nejsou dosaženy limity úložiště. Například virtuální počítač, na kterém běží proces náročný na procesor, například šifrování dat, může zpozdit SQL Server vstupně-výstupní operace, což vede k pomalejší době odezvy dotazů.
Insufficient memory on the VM: V SQL Serveru je paměť klíčová pro ukládání dat do mezipaměti, což snižuje potřebu diskových vstupně-výstupních operací. Pokud je paměť omezená, SQL Server může být potřeba číst z disku častěji, což zvyšuje latenci. To je obzvláště relevantní u virtuálních počítačů s menší pamětí nebo když procesy na pozadí náročné na paměť soupeří o prostředky. To může nepřímo zvýšit latenci úložiště, protože k zpracování úlohy jsou potřeba častější diskové operace, a to i v případě, že nejsou dosaženy limity IOPS.
: Jiné procesy na virtuálním počítači , jako je antivirový software, zálohování nebo úlohy údržby (například Windows Update) – můžou spotřebovávat prostředky procesoru, paměti nebo vstupně-výstupních operací disku, které zpožďují SQL Server operace. Neefektivní ovladače filtru můžou tento účinek zhoršit. Tyto procesy soupeří s SQL Server pro systémové prostředky, což způsobuje zpoždění vstupně-výstupních operací, která se zobrazují jako latence úložiště. Například antivirová kontrola, která čte mnoho souborů současně, může snížit šířku pásma disku dostupnou pro SQL Server, což zvyšuje latenci databázových transakcí. Kromě toho, že nemáte správná antivirová vyloučení, může docílit problémů s latencí, aniž by došlo k omezování SQL Server na virtuálních počítačích Azure, a to především zvýšením vstupně-výstupních operací disku, filtrováním rušení ovladačů a konkurencem prostředků.
Využití úložiště nižší třídy: Volba možností úložiště nižší třídy, jako jsou standardní disky HDD, namísto prémiových SSD nebo ultra disků, způsobuje vyšší základní latenci kvůli inherentnímu návrhu těchto disků, a to i bez dosažení limitů IOPS. I když nákladově efektivní, méněúrovňové úložiště není optimalizované pro úlohy citlivé na výkon SQL Server, což vede k pomalejšímu přístupu k datům. Například zákazník, který k úsporě nákladů používá disky HDD úrovně Standard, může mít nižší výkon dotazů kvůli přirozeně vyšší latenci disků.
Nedostatečná konfigurace úložiště: Selhání konfigurace úložiště pro optimalizaci SQL Server úloh může vést k latenci bez omezování. Například nesprávné nastavení ukládání do mezipaměti disku může snížit výkon. Microsoft doporučuje povolit cache jen pro čtení pro datové disky a zakázat cache pro disky protokolu při použití Premium SSD v1 se SQL Serverem na virtuálních počítačích Azure. Chybně nakonfigurované ukládání do mezipaměti může zpomalit operace čtení nebo zápisu. Například zakázání ukládání do mezipaměti pro čtení na datovém disku, který je hostitelem SQL Server datových souborů, snižuje efektivitu úloh náročných na čtení a zvyšuje latenci.
SQL Server kolize databáze: Neefektivní dotazy (například prohledávání úplné tabulky místo indexovaného vyhledávání) nebo kolize uzamčení v rámci SQL Server může zvýšit poptávku po vstupně-výstupních operacích nebo zpozdit přístup k datům, což se projevuje jako latence úložiště. Problémy na úrovni aplikace můžou zatížit subsystém úložiště bez překročení limitů, zejména u malých, náhodných vstupně-výstupních vzorů běžných v transakčních úlohách. Například špatně optimalizovaný dotaz, který provádí úplnou kontrolu tabulky u velké datové sady, bude číst nadměrná data z disku, což zvyšuje zatížení vstupně-výstupních operací a latenci v porovnání s indexovaným dotazem.

Pokud dochází k latenci bez škrcení, zvažte následující kroky k řešení latence:

Monitor a správa využití procesoru: Sledování využití procesoru pomocí nástrojů, jako jsou Azure Monitor nebo Monitorování prostředků. Pokud je zatížení procesoru vysoké, optimalizujte dotazy SQL nebo upgradujte na virtuální počítač s více virtuálními jádry.
Monitorovat využití paměti: Ujistěte se, že velikost virtuálního počítače má dostatek paměti pro úlohu SQL Serveru, pomocí velikostí VM, jako je řada E-series nebo M-series s vyšším poměrem paměti na virtuální jádra. Monitorování využití paměti pomocí Performance Monitor nebo Azure Monitor k identifikaci bodů tlaku V případě potřeby zvažte vertikální navýšení kapacity paměti.
Plánujte úlohy na pozadí pečlivě: Spouštějte úlohy náročné na prostředky (například zálohování nebo antivirové kontroly) mimo špičkové hodiny, abyste se vyhnuli konkurenci SQL Serveru o prostředky.
Vyberte správnou úroveň úložiště: Vyhodnoťte, jestli úložiště nižší vrstvy (např. HDD úrovně Standard) splňuje vaše požadavky na výkon. U důležitých SQL Server úloh zvolte disky SSD úrovně Premium nebo disky Úrovně Ultra, aby se minimalizovala latence.
Nakonfigurujte mezipaměť správně: Pro SSD úrovně Premium (v1) nenastavujte mezipaměť pro logovací disky a nastavte mezipaměť jen pro čtení pro datové disky. Ověřte nastavení po změně virtuálního počítače nebo úložiště, protože disky SSD úrovně Premium v2 a Ultra nepodporují ukládání do mezipaměti.
Optimalizujte výkon SQL serveru: Zkontrolujte a vylaďte dotazy, abyste snížili zátěž na vstupně-výstupní operace. Implementujte indexy, vyhněte se plným skenům tabulek a vyřešte blokování, abyste zvýšili efektivitu. Pomocí funkce analýzy osvědčených postupů identifikujte možnosti konfigurace, které můžou zlepšit výkon.
Ujistěte se, že jsou správná vyloučení antivirového softwaru: Implementace správných vyloučení, testování při zatížení a plánování kontrol může odpovídajícím způsobem zmírnit problémy s latencí a zajistit optimální výkon s vyrovnáváním zabezpečení.

Vzhledem k tomu, že špatně nakonfigurované systémy úložiště můžou vést k problémům s výkonem, můžete použít podokno Storage na portálu Azure a spustit podmnožinu osvědčených postupů pro SQL k identifikaci problémů s konfigurací úložiště s SQL Server na virtuálních počítačích Azure. Funkce osvědčených postupů SQL je založená na rozhraní SQL Assessment API.

Můžete si prohlédnout plný seznam doporučení k GitHub. Filtrováním sloupce id podle pravidel na GitHubu můžete v podokně I/O konfiguračních osvědčených postupů na kartě Storage zobrazit pravidla konfigurace disků virtuálního počítače SQL, která jsou ověřována pro váš prostředek SQL virtuální stroje v Azure portálu.

AzSqlVmSize
AzDataDiskCache
AzDataDiskStriping
AzDataNaDatovýchDiscích
AzDbDefaultLocation
AzDiskColumnCount

AzErrorLogLocation
AzPremSsdDataFiles
AzTempDbFileLocation
AzTranLogDiskCache
NtfsBlockVelikostNeformátovaná
ZamčenéStránkyVPaměti

Na kartě Osvědčené postupy související s vstupně-výstupními operacemi spusťte posouzení a spusťte posouzení konfigurace, která by měla trvat několik minut (pokud neexistuje velký počet databází a objektů). Případně pokud se zobrazí časové razítko nejnovějších dostupných výsledků, můžete pomocí funkce Fetch nejnovější výsledky zkontrolovat zjištění z předchozích hodnocení.

Analýza vstupně-výstupních operací pomocí PowerShellu

K analýze výkonu vstupně-výstupních operací virtuálního počítače SQL Server můžete použít také skript PowerShell I/O Analysis:

# Enter parameters
$subscriptionId = Read-Host "<Subscription ID>"
$resourceGroup = Read-Host "<Resource Group>"
$vmName = Read-Host "<Virtual machine name>"

# Set resource details
$resourceType = "Microsoft.Compute/virtualMachines"
$resourceId = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/$resourceType/$vmName"

# Get Azure access token
$accessToken = az account get-access-token --query accessToken -o tsv

# Invoke Azure Monitor Metrics API
function Get-Metrics {
    [CmdletBinding()]
    param (
        [string]$accessToken,
        [string]$resourceId,
        [string]$metricNames,
        [string]$apiVersion = "2023-10-01"
    )
    try {
        $startTime = (Get-Date).AddHours(-24).ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')
        $endTime = (Get-Date).ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')
        $timespan = "$startTime/$endTime"
        Write-Verbose "Evaluating timespan: $timespan"
        $uri = "https://management.azure.com$resourceId/providers/Microsoft.Insights/metrics?api-version=$apiVersion&metricnames=$metricNames&aggregation=maximum&interval=PT1M&timespan=$timespan"
        $headers = @{ "Authorization" = "Bearer $accessToken"; "Content-Type" = "application/json" }
        
        $response = Invoke-RestMethod -Uri $uri -Headers $headers -Method Get
        if ($response) {
            Write-Verbose "API response successfully retrieved."
            return $response
        } else {
            Write-Error "No response from API."
        }
    } catch {
        Write-Error "Error retrieving metrics: $_"
    }
}

# Check if data disk latency violates thresholds
function Check-Latency {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [Object]$metrics,

        [Parameter()]
        [int]$latencyThreshold = 500,

        [Parameter()]
        [int]$consecutiveCount = 5
    )
    $violationTimes = @()
    foreach ($metric in $metrics.value) {
        if ($metric.name.value -eq "Data Disk Latency") {
            $count = 0
            foreach ($dataPoint in $metric.timeseries[0].data) {
                if ($dataPoint.maximum -gt $latencyThreshold) {
                    $count++
                    if ($count -ge $consecutiveCount) {
                        $violationTimes += $dataPoint.timeStamp
                        $count = 0  # Reset count after recording a violation
                    }
                } else {
                    $count = 0  # Reset count if the sequence is broken
                }
            }
        }
    }
    if ($violationTimes.Count -gt 0) {
        Write-Verbose "Latency violations detected."
        return @{ "Flag" = $true; "Times" = $violationTimes }
    } else {
        Write-Verbose "No latency violations detected."
        return @{ "Flag" = $false }
    }
}

# Check metrics other than latency to evaluate for throttling
function Check-OtherMetricsThrottled {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [Object]$metrics,

        [Parameter()]
        [int]$PercentageThreshold = 90,

        [Parameter()]
        [int]$consecutiveCount = 5
    )
    $violatedMetrics = @()
    foreach ($metric in $metrics.value) {
        $count = 0
        foreach ($dataPoint in $metric.timeseries[0].data) {
            if ($dataPoint.maximum -gt $PercentageThreshold) {
                $count++
                if ($count -ge $consecutiveCount) {
                    $violatedMetrics += @{ "Metric" = $metric.name.localizedValue; "Time" = $dataPoint.timeStamp; "Value" = $dataPoint.maximum }
                    break
                }
            } else {
                $count = 0
            }
        }
    }
    if ($violatedMetrics.Count -gt 0) {
        Write-Verbose "Other metrics violations detected."
    } else {
        Write-Verbose "No other metrics violations detected."
    }
    return $violatedMetrics
}

# Compare times for latency & other throttled metrics. Logs the volations with values & timestamps
function CompareTimes {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true)]
        [Hashtable]$latencyResult,
        
        [Parameter(Mandatory = $true)]
        [Array]$otherMetrics
    )
    foreach ($metric in $otherMetrics) {
        $otherDateTime = [DateTime]$metric["Time"]
        $isWithinFiveMinutes = $false
        $closestLatencyTime = $null
        $closestTimeDifference = [int]::MaxValue

        foreach ($latencyTime in $latencyResult.Times) {
            $latencyDateTime = [DateTime]$latencyTime
            $timeDifference = [Math]::Abs(($otherDateTime - $latencyDateTime).TotalMinutes)
            
            if ($timeDifference -le 5) {
                $isWithinFiveMinutes = $true
                if ($timeDifference -lt $closestTimeDifference) {
                    $closestTimeDifference = $timeDifference
                    $closestLatencyTime = $latencyTime
                }
            }
        }

        if ($isWithinFiveMinutes) {
            if ($otherDateTime -lt $closestLatencyTime) {
                Write-Host "`n $($metric["Metric"]) limit was hit before latency spiked at $closestLatencyTime with value $($metric["Value"]). `n"
            } else {
                Write-Host "`n $($metric["Metric"]) hit its limit with value $($metric["Value"]) at $($metric["Time"])."
                Write-Host "Latency spiked at $closestLatencyTime before $($metric["Metric"]) hit its limit `n"
            }
        } else {
            Write-Host "`n Metric: $($metric["Metric"]) exceeded its threshold with a value of $($metric["Value"]) at $($metric["Time"]), but this was not within 5 minutes of any latency spikes."
        }
    }
}

# Prompt user for latency threshold
$latencyThreshold = Read-Host "Enter Latency Threshold (default is 500)"
if (-not [int]::TryParse($latencyThreshold, [ref]0)) {
    $latencyThreshold = 500 # Use default if invalid input
    Write-Host "No valid input provided. Using Default 500ms for disk latency threshold"
}

# Execute main logic
$latencyMetrics = Get-Metrics -accessToken $accessToken -resourceId $resourceId -metricNames "Data Disk Latency"
$latencyResult = Check-Latency -metrics $latencyMetrics -latencyThreshold $latencyThreshold

if ($latencyResult.Flag) {
    
    # If latency is flagged, check for other metrics. If there is no disk latency, machine is likely not throttled but only at high consumption
    Write-Verbose "Checking the following metrics: Data Disk Bandwidth Consumed Percentage,Data Disk IOPS Consumed Percentage,VM Cached Bandwidth Consumed Percentage,VM Cached IOPS Consumed Percentage,VM Uncached Bandwidth Consumed Percentage,VM Uncached IOPS Consumed Percentage"
    
    $DiskVMMetrics = Get-Metrics -accessToken $accessToken -resourceId $resourceId -metricNames "Data Disk Bandwidth Consumed Percentage,Data Disk IOPS Consumed Percentage,VM Cached Bandwidth Consumed Percentage,VM Cached IOPS Consumed Percentage,VM Uncached Bandwidth Consumed Percentage,VM Uncached IOPS Consumed Percentage"
    
    $additionalMetrics = Check-OtherMetricsThrottled -metrics $DiskVMMetrics
    
    if ($additionalMetrics.Count -gt 0) {
        CompareTimes $latencyResult $additionalMetrics
    } else {
        Write-Host "No metrics violations detected besides latency."
    }
} else {
    Write-Host "No latency issues detected."
}

Další kroky

Spuštěním posouzení osvědčených postupů SQL identifikujte potenciální chybné konfigurace, které by mohly vést k problémům s výkonem.

Váš názor

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

Last updated on 2026-03-11