Sdílet prostřednictvím

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

  • Článek

Platí pro: SQL Server na virtuálním počítači Azure

Tento článek vás naučí analyzovat výkon vstupně-výstupních operací pro SQL Server na virtuálních počítačích Azure a zjistit problémy, které vyplývají z překročení limitů virtuálních počítačů a datových disků.

Poznámka:

Analýza vstupně-výstupních operací pro SQL Server na virtuálních počítačích Azure na webu Azure Portal je aktuálně ve verzi Preview.

Přehled

I když různé nástroje pomáhají řešit problémy s výkonem SQL Serveru, aby to bylo možné efektivně provést na virtuálním počítači Azure, je důležité pochopit, co se děje na úrovni hostitele i na instanci SQL Serveru, kde může být často náročné korelace metrik hostitele s úlohami SQL Serveru. SQL Server na virtuálních počítačích Azure usnadňuje 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 webu Azure Portal a dají se dotazovat pomocí Azure CLI.

Podokno Úložiště prostředku virtuálních počítačů SQL na webu Azure Portal 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

Principy metrik

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. Metriky Azure se vzorkují každých 30 sekund a agregují se do minuty.

Systém monitoruje omezování a latenci disku. Očekává se určité omezování a bude ignorováno, pokud není k dispozici také 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 metriky Azure používané k identifikaci problematických problémů s omezováním:

Metrika Azure Popis metriky Problematický stav Závěry omezování vstupně-výstupních operací
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í Došlo k problému s latencí, kvůli které systém může dále prošetřit potenciální omezování.
Procento IOPS mezipaměti využité virtuálním počítačem 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é celkovou propustností disku se dokončilo nad 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é celkovým počtem vstupně-výstupních operací za sekundu na virtuálním počítači se dokončilo nad maximálním limitem IOPS necached 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í 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é celkovou propustností disku na virtuálním počítači se dokončilo nad maximální zřízenou propustností 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 Procento vypočítané IOPS datového disku se dokončilo oproti IOPS zřízeného datového disku. >= 95 % v po sobě jdoucím 5minutovém období Dochází k 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 Procento vypočítané propustností datového disku se dokončilo při propustnosti zřízeného datového disku. >= 95 % v po sobě jdoucím 5minutovém období Dochází k 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 omezování
  • 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 vstupně-výstupních operací

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. Kontrolní seznam osvědčených postupů pro SQL Server na virtuálních počítačích Azure můžete použít k zajištění efektivní konfigurace systému nebo vyhledání užitečných odkazů pro řešení potíží s výkonem SQL Serveru. Pokud povolíte funkci posouzení osvědčených postupů SQL, zobrazí se úplný seznam doporučení pro virtuální počítač s SQL Serverem.

Problém s omezováním 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 úlohy SQL Serveru obecně platí, že doporučená řada pro úlohy SQL Serveru jsou ty optimalizované pro paměť, jako jsou ř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 instanci SQL Serveru. 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 do Azure, můžete použít nástroje, jako jsou datové Pomocník s migrací a doporučení skladové položky, analyzovat aktuální konfiguraci a využití SQL Serveru 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í, že úloha se omezuje z překročení limitů, které virtuální počítač stanoví:

  • Procento IOPS mezipaměti využité virtuálním počítačem
  • Procento šířky pásma mezipaměti využité virtuálním počítačem
  • Procento IOPS mimo mezipaměť využité virtuálním počítačem
  • Procento šířky pásma mimo mezipaměť využité 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 omezování je možné vyřešit laděním úloh, zatímco trvalé špičky můžou značit, že základní úložiště nedokáže zpracovat zatížení.

Problém s omezováním 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í, že úloha je omezena z překročení limitů, které disk ukládá:

  • 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 Serveru. Doporučujeme umístit data SQL Serveru (.mdf) a soubory protokolu (.df) na datový disk.

  • Pokud je k dispozici omezování na úrovni datového disku, povolte ukládání do mezipaměti pro čtení.

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 můžou vést k nadměrné aktivitě vstupně-výstupních operací, které spotřebovávají více vstupně-výstupních operací, než se čekalo. 
  • 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 vstupně-výstupních operací za sekundu a pokud požadavky aplikace překročí tento limit, počet vstupně-výstupních operací vstupně-výstupních operací za sekundu 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í disku: 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

Procento využití šířky pásma datového disku v 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.
  • Distribuce dat mezi více disků pomocí technik, jako je dělení nebo horizontální dělení
  • 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.

Tip

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ů.

Vzhledem k tomu, že špatně nakonfigurované systémy úložiště můžou vést k problémům s výkonem, můžete pomocí podokna Úložiště na webu Azure Portal spustit podmnožinu osvědčených postupů SQL, která identifikují problémy s konfigurací úložiště na virtuálních počítačích Azure. Funkce osvědčených postupů SQL je založená na rozhraní SQL Assessment API.

Úplný seznam doporučení můžete zobrazit na GitHubu. Filtrováním sloupce ID v pravidlech na GitHubu můžete zobrazit pravidla konfigurace disků virtuálního počítače SQL, která jsou ověřená na kartě Osvědčené postupy konfigurace vstupně-výstupních operací v podokně Úložiště pro prostředek virtuálních počítačů SQL na webu Azure Portal.

  • AzSqlVmSize
  • AzDataDiskCache
  • AzDataDiskStriping
  • AzDataOnDataDisks
  • AzDbDefaultLocation
  • AzDiskColumnCount
  • AzErrorLogLocation
  • AzPremSsdDataFiles
  • AzTempDbFileLocation
  • AzTranLogDiskCache
  • NtfsBlockSizeNotFormatted
  • LockedPagesInMemory

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 s SQL Serverem můžete použít také skript PowerShellu pro analýzu vstupně-výstupních operací:

# 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.