Analiza wydajności we/wy (wersja zapoznawcza) — program SQL Server na maszynach wirtualnych platformy Azure
Dotyczy: 
program SQL Server na maszynie wirtualnej platformy Azure
W tym artykule pokazano, jak analizować wydajność operacji we/wy dla programu SQL Server na maszynach wirtualnych platformy Azure, aby znaleźć problemy wynikające z przekroczenia limitów maszyn wirtualnych i dysków danych.
Uwaga
Analiza we/wy dla programu SQL Server na maszynach wirtualnych platformy Azure w witrynie Azure Portal jest obecnie dostępna w wersji zapoznawczej.
Omówienie
Mimo że różne narzędzia ułatwiają rozwiązywanie problemów z wydajnością programu SQL Server, aby to zrobić skutecznie na maszynie wirtualnej platformy Azure, ważne jest, aby zrozumieć, co dzieje się zarówno na poziomie hosta, jak i w wystąpieniu programu SQL Server, gdzie często korelowanie metryk hosta z obciążeniami programu SQL Server może być wyzwaniem. Program SQL Server na maszynach wirtualnych platformy Azure ułatwia identyfikowanie problemów z wydajnością wynikających z liczby operacji we/wy na sekundę (wejścia/wyjścia na sekundę) i ograniczania przepływności spowodowanych przekroczeniem limitów maszyn wirtualnych i dysków danych.
Metryki wydajności, które demonstrują problem i potencjalne kroki umożliwiające jego rozwiązanie, są dostępne w witrynie Azure Portal i można wykonywać zapytania za pomocą interfejsu wiersza polecenia platformy Azure.
Okienko Magazyn zasobu maszyn wirtualnych SQL w witrynie Azure Portal ułatwia:
- Zarządzanie konfiguracją magazynu
- Identyfikowanie ograniczania operacji we/wy
- Ocena systemu pod kątem najlepszych rozwiązań związanych z we/wy
Informacje o metrykach
Karta Analiza we/wy opiera się na metrykach platformy Azure w celu zidentyfikowania opóźnienia dysku oraz ograniczenia operacji we/wy dysku lub maszyny wirtualnej. Metryki platformy Azure są próbkowane co 30 sekund i agregowane do minuty.
System monitoruje ograniczanie przepustowości i opóźnienie dysku. Oczekiwane jest ograniczenie przepustowości i jest ignorowane, chyba że występuje również opóźnienie dysku. Jeśli w ciągu kolejnych 500 milisekund opóźnienia dysku zaobserwowano ponad 500 milisekund, system:
- Szczegółowe informacje na temat metryk wydajności
- Identyfikuje zasób ograniczony
- Zapewnia potencjalne główne przyczyny i kroki ograniczania ryzyka
W poniższej tabeli opisano metryki platformy Azure używane do identyfikowania problematycznych problemów z ograniczaniem przepustowości:
| Metryka platformy Azure | Opis metryki | Problematyczny warunek | Wnioski dotyczące ograniczania operacji we/wy |
|---|---|---|---|
| Opóźnienie dysku (wersja zapoznawcza) | Średni czas ukończenia operacji we/wy dla dysku danych w monitorowanym okresie. Wartości są w milisekundach. | > 500 milisekund w kolejnych 5-minutowych okresach | Wystąpił problem z opóźnieniem systemu w celu dalszego zbadania potencjalnego ograniczania przepustowości. |
| Procent zużycia buforowanych operacji we/wy na sekundę przez maszynę wirtualną | Wartość procentowa obliczona przez łączną liczbę operacji we/wy na sekundę ukończoną przez maksymalny limit liczby operacji we/wy na sekundę maszyny wirtualnej w pamięci podręcznej. | >= 95% w kolejnym okresie 5 minut | Istnieje ograniczenie przepustowości maszyny wirtualnej. Aplikacja uruchomiona na maszynie wirtualnej SQL w pełni korzysta z maksymalnej pojemności operacji we/wy na sekundę buforowanej dostępnej dla maszyny wirtualnej — zapotrzebowanie na magazyn aplikacji przekracza buforowane operacje we/wy na sekundę dostarczone przez podstawową konfigurację magazynu maszyny wirtualnej. |
| Procent użycia przepustowości pamięci podręcznej maszyny wirtualnej | Wartość procentowa obliczona przez łączną przepływność dysku ukończoną przez maksymalną przepływność maszyny wirtualnej w pamięci podręcznej. | >= 95% w kolejnym okresie 5 minut | Istnieje ograniczenie przepustowości maszyny wirtualnej. Aplikacja uruchomiona na maszynie wirtualnej SQL korzysta z maksymalnej dostępnej przepustowości dysku buforowanego na potrzeby transferu danych — zapotrzebowanie na transfer danych aplikacji przekracza buforowane zasoby przepustowości udostępniane przez podstawową konfigurację magazynu maszyny wirtualnej. |
| Procent zużycia niebuforowanych operacji we/wy na sekundę przez maszynę wirtualną | Wartość procentowa obliczona przez łączną liczbę operacji we/wy na sekundę na maszynie wirtualnej została ukończona przez maksymalny limit liczby operacji we/wy na sekundę maszyny wirtualnej bezcache. | >= 95% w kolejnym okresie 5 minut | Istnieje ograniczenie przepustowości maszyny wirtualnej. Aplikacja uruchomiona na maszynie wirtualnej SQL korzysta z maksymalnej dozwolonej pojemności operacji we/wy na sekundę, która jest dostępna dla maszyny wirtualnej — zapotrzebowanie na magazyn aplikacji przekracza zasoby bez użycia operacji we/wy na sekundę udostępniane przez podstawową konfigurację magazynu maszyny wirtualnej. |
| Procent zużycia niebuforowanej przepustowości przez maszynę wirtualną | Wartość procentowa obliczona przez łączną przepływność dysku na maszynie wirtualnej została ukończona przez maksymalną aprowizowaną przepływność maszyny wirtualnej. | >= 95% w kolejnym okresie 5 minut | Istnieje ograniczenie przepustowości maszyny wirtualnej. Aplikacja uruchomiona na maszynie wirtualnej SQL korzysta z maksymalnej dozwolonej przepustowości dysku niebuforowanego na potrzeby transferu danych — zapotrzebowanie na transfer danych aplikacji przekracza zasoby przepustowości niebuforowanej udostępniane przez podstawową konfigurację magazynu maszyny wirtualnej. |
| Procent zużycia operacji we/wy dysku danych na sekundę | Wartość procentowa obliczona przez liczbę operacji we/wy na sekundę dysku danych została ukończona przez aprowizowaną liczbę operacji we/wy na sekundę dysku danych. | >= 95% w kolejnym okresie 5 minut | Istnieją ograniczenia dysku danych. Aplikacja uruchomiona na maszynie wirtualnej SQL osiąga limit liczby operacji we/wy na sekundę dla aprowizowanego dysku danych — wymagania dotyczące magazynu aplikacji przekraczają możliwości wydajności wybranej konfiguracji dysku. |
| Procent zużycia przepustowości dysku danych | Wartość procentowa obliczona przez przepływność dysku danych ukończona przez aprowizowaną przepływność dysku danych. | >= 95% w kolejnym okresie 5 minut | Istnieją ograniczenia dysku danych. Aplikacja uruchomiona na maszynie wirtualnej SQL osiąga limit liczby operacji we/wy na sekundę dla aprowizowanego dysku danych — wymagania dotyczące magazynu aplikacji przekraczają możliwości wydajności wybranej konfiguracji dysku. |
Wyniki analizy we/wy
Na podstawie analizy metryk wydajności w ciągu ostatnich 24 godzin analiza we/wy określa, że istnieją następujące elementy:
- Brak ograniczania przepustowości
- Ograniczanie operacji we/wy na poziomie maszyny wirtualnej
- Ograniczanie operacji we/wy na poziomie dysku
Brak problemu z ograniczaniem operacji we/wy
Jeśli występuje problem z wydajnością, ale nie ma opóźnienia dysku, problem z wydajnością nie jest spowodowany problemem z ograniczaniem operacji we/wy. Należy zbadać inne obszary. Możesz użyć listy kontrolnej Najlepszych rozwiązań dla programu SQL Server na maszynach wirtualnych platformy Azure, aby upewnić się, że system jest skonfigurowany wydajnie lub znaleźć przydatne linki do rozwiązywania problemów z wydajnością programu SQL Server. Jeśli włączysz funkcję oceny najlepszych rozwiązań SQL, zobaczysz pełną listę zaleceń dotyczących maszyny wirtualnej z programem SQL Server.
Problem z ograniczaniem operacji we/wy na poziomie maszyny wirtualnej
Usługa Azure Virtual Machines to zasoby obliczeniowe oparte na chmurze, które są dostępne w różnych seriach i rozmiarach dla różnych obciążeń, z których każda ma różne możliwości i charakterystykę wydajności. W przypadku obciążeń programu SQL Server, ogólnie rzecz biorąc, zalecaną serią obciążeń programu SQL Server są te zoptymalizowane pod kątem pamięci, takie jak Ebdsv5, M i Mv2.
Rozmiar maszyny wirtualnej określa liczbę procesorów wirtualnych, pamięci i magazynu dostępnego dla wystąpienia programu SQL Server. W porównaniu z magazynem klienci mogą stosunkowo łatwo zmienić rozmiar maszyn wirtualnych i skalować maszynę wirtualną w górę i w dół na podstawie potrzeb związanych z zasobami aplikacji. Ponieważ istnieje możliwość ograniczenia liczby operacji we/wy na sekundę i przepływności na poziomie maszyny wirtualnej, wybierz odpowiedni rozmiar maszyny wirtualnej na podstawie potrzeb związanych z wydajnością i kosztem obciążenia.
Jeśli przeprowadzasz migrację na platformę Azure, możesz użyć narzędzi, takich jak zalecenia dotyczące danych Asystent migracji i jednostek SKU, aby przeanalizować bieżącą konfigurację i użycie programu SQL Server oraz zasugerować najlepszy rozmiar maszyny wirtualnej dla obciążenia na platformie Azure.
Następujące metryki platformy Azure służą do określania, że obciążenie jest ograniczane z przekroczenia limitów narzuconych przez maszynę wirtualną:
- Procent zużycia buforowanych operacji we/wy na sekundę przez maszynę wirtualną
- Procent zużycia buforowanej przepustowości przez maszynę wirtualną
- Procent zużycia niebuforowanych operacji we/wy na sekundę przez maszynę wirtualną
- Procent zużycia niebuforowanej przepustowości przez maszynę wirtualną
Rozważ następujące kluczowe kwestie dotyczące ograniczania przepustowości maszyny wirtualnej:
- Pamięć, rdzenie wirtualne, przepływność i liczba operacji we/wy na sekundę można zwiększyć, zmieniając rozmiar maszyny wirtualnej w ramach serii maszyn wirtualnych.
- Nie można zmniejszyć rozmiaru maszyny wirtualnej do poziomu, w którym liczba dysków danych przekracza maksymalny limit dysków danych dla docelowego rozmiaru maszyny wirtualnej.
- Ważne jest, aby określić wzorzec ograniczania przepustowości. Na przykład rzadko występujące skoki ograniczania przepustowości mogą być prawdopodobnie rozwiązane przez dostrajanie obciążenia, podczas gdy trwałe skoki mogą wskazywać, że bazowy magazyn nie jest w stanie obsłużyć obciążenia.
Problem z ograniczaniem operacji we/wy na poziomie dysku
W przypadku klientów maszyn wirtualnych SQL magazyn jest najbardziej krytycznym aspektem, który należy odpowiednio skonfigurować pod kątem zoptymalizowanej wydajności, ponieważ modyfikowanie magazynu jest trudniejsze niż zmiana rozmiaru maszyny wirtualnej. Na przykład wprowadzenie zmian w celu zwiększenia liczby operacji we/wy na sekundę lub przepływności dysków SSD w warstwie Premium wymaga utworzenia nowej puli magazynów. W związku z tym kluczowe jest zoptymalizowanie konfiguracji magazynu zarówno pod kątem ceny, jak i wydajności podczas fazy planowania, aby uniknąć problemów z wydajnością po wdrożeniu.
Następujące metryki platformy Azure służą do określania, że obciążenie jest ograniczane z przekroczenia limitów narzuconych przez dysk:
Procent zużycia operacji we/wy dysku danych na sekundę
Procent użycia przepustowości dysku danych Rozważ następujące kluczowe kwestie dotyczące ograniczania operacji we/wy na poziomie dysku:
Dysk danych ma krytyczne znaczenie dla wydajności programu SQL Server. Zalecane jest umieszczenie danych programu SQL Server (.mdf) i plików dziennika (df) na dysku danych.
W przypadku ograniczania na poziomie dysku danych włącz buforowanie odczytu, jeśli jest dostępne.
Procent zużycia operacji we/wy dysku danych na sekundę
Liczba operacji we/wy na sekundę dysku danych zużywana w procentach mierzy użycie operacji we/wy na sekundę na poziomie dysku. Ogólnie rzecz biorąc, wysokie wymagania dotyczące liczby operacji we/wy na sekundę są skojarzone z wysoce transakcyjnymi aplikacjami i obciążeniami opartymi na protokole OLTP. Następujące scenariusze lub warunki mogą potencjalnie przekraczać limity liczby operacji we/wy na sekundę dysku danych:
- Duże obciążenie transakcji (IOPS): jeśli aplikacja przetwarza dużą liczbę transakcji bazy danych, które obejmują częste operacje odczytu i zapisu, może szybko korzystać z przydzielonych operacji we/wy na sekundę.
- Nieefektywne zapytania: źle zoptymalizowane zapytania SQL lub operacje pobierania danych mogą prowadzić do nadmiernego działania we/wy, zużywając więcej operacji we/wy niż oczekiwano.
- Użytkownicy współbieżni: jeśli wielu użytkowników lub sesji jednocześnie uzyskuje dostęp do bazy danych i generuje żądania we/wy, skumulowany efekt może spowodować osiągnięcie limitu liczby operacji we/wy na sekundę.
- Zasoby rywalizujące: jeśli podstawowa infrastruktura fizyczna jest w dużym stopniu współdzielona z innymi dzierżawami lub obciążeniami, może to mieć wpływ na dostępną operację we/wy na sekundę dla maszyny wirtualnej.
- Tymczasowe wzrosty: tymczasowe skoki obciążenia, takie jak przetwarzanie wsadowe lub migracje danych, mogą prowadzić do nagłego wzrostu zapotrzebowania we/wy, które przewyższają przydzieloną liczbę operacji we/wy na sekundę.
- Mały rozmiar dysku: jeśli aprowizowany rozmiar dysku danych jest stosunkowo mały, pojemność operacji we/wy na sekundę może być ograniczona. Poszczególne mniejsze dyski mają mniejsze limity liczby operacji we/wy na sekundę, a jeśli zapotrzebowanie aplikacji przekroczy ten limit, wartość procentowa użycia operacji we/wy na sekundę dysku danych osiągnie 100%.
- Niewystarczający typ dysku: wybranie typu dysku o niższej wydajności (na przykład hdd w warstwie Standardowa) dla aplikacji intensywnie korzystającej z operacji we/wy może prowadzić do ograniczeń liczby operacji we/wy na sekundę.
- Niezoptymalizowany rozmiar paska dysku: jeśli konfiguracja magazynu nie jest zoptymalizowana pod kątem obciążenia, może to prowadzić do nieoptymalnego zwiększenia wydajności operacji we/wy na sekundę.
Rozważ następujące kroki, aby uniknąć przekroczenia limitu liczby operacji we/wy na sekundę dysku danych:
- Zoptymalizuj zapytania SQL i projekt bazy danych, aby zminimalizować niepotrzebne operacje we/wy.
- Wybierz odpowiedni typ dysku (SSD w warstwie Standardowa lub SSD w warstwie Premium), który jest zgodny z wymaganiami dotyczącymi liczby operacji we/wy na sekundę aplikacji.
- Użyj większych rozmiarów dysków, aby zwiększyć dostępną pojemność operacji we/wy na sekundę.
- Dystrybuuj operacje we/wy na wielu dyskach danych przy użyciu konfiguracji RAID.
Procent użycia przepustowości dysku danych
Przepustowość dysku danych zużywana procentowa metryka platformy Azure mierzy wykorzystanie przepustowości na poziomie dysku. Ogólnie rzecz biorąc, potrzeby dotyczące wysokiej przepływności są skojarzone z magazynowaniem danych, składnicą danych, raportowaniem, ETL i innymi obciążeniami analitycznymi danych.
Następujące scenariusze lub warunki mogą potencjalnie przekraczać limity przepustowości dysku danych:
- Transfer dużych ilości danych: częste transfery danych aplikacji na dużą skalę między dyskiem a bazą danych SQL mogą szybko korzystać z dostępnej przepustowości dysku danych.
- Zbiorcze ładowanie danych: działania transferu dysków skojarzone z operacjami wstawiania, aktualizacji lub importowania danych zbiorczych mogą prowadzić do wysokiego zużycia przepustowości.
- Magazynowanie lub analiza danych: aplikacje, które obejmują duże ilości magazynowania danych, przetwarzania analiz lub raportowania, mogą generować znaczne przenoszenie danych, co może spowodować przekroczenie limitów przepustowości.
- Technologia/replikacja o wysokiej nadmiarowości danych: kopiowanie danych skojarzone z użyciem replikacji opartej na dysku, dublowania danych lub innych mechanizmów nadmiarowości może przyczynić się do nasycenia przepustowości.
- Tworzenie i przywracanie danych: Częste kopie zapasowe danych, migawki lub procesy przywracania mogą zużywać znaczną przepustowość dysku danych.
- Równoległe wykonywanie zapytań: Zapytania równoległe, które obejmują duże skanowania lub sprzężenia danych, mogą prowadzić do znacznego przenoszenia danych, co powoduje wykorzystanie przepustowości.
- Podwyższony ruch sieciowy: Duża aktywność sieci, taka jak transfer danych między maszyną wirtualną i innymi zasobami, może pośrednio wpływać na dostępność przepustowości dysku danych.
- Niewystarczający typ dysku: wybranie typu dysku o niższej wydajności dla aplikacji z wysokimi wymaganiami dotyczącymi transferu danych może prowadzić do przekroczenia limitu przepustowości.
- Współbieżne operacje intensywnie korzystające z danych: łączny efekt wielu współbieżnych procesów lub sesji uzyskujących dostęp do danych na tym samym dysku może spowodować osiągnięcie limitu przepustowości.
- Niezoptymalizowane zapytania lub procesy ETL: słabo zoptymalizowane zapytania SQL lub procesy wyodrębniania, przekształcania, ładowania (ETL) mogą prowadzić do nadmiernego przenoszenia danych, co skutkuje nadmiernym zużyciem przepustowości.
Rozważ następujące kroki, aby uniknąć przekroczenia limitu przepustowości dysku danych:
- Zoptymalizuj operacje transferu danych, aby zminimalizować niepotrzebne przenoszenie danych.
- Rozważ użycie typów dysków o wyższej wydajności, które oferują większą przepustowość, na przykład SSD w warstwie Premium lub SSD w warstwie Premium w wersji 2.
- Dystrybuuj dane na wielu dyskach przy użyciu technik, takich jak partycjonowanie lub dzielenie na fragmenty.
- Optymalizowanie i równoległe wykonywanie zapytań i przetwarzania danych w celu zmniejszenia przenoszenia danych.
- Użyj mechanizmów kompresji i wydajnego przechowywania danych, aby zmniejszyć ilość przesyłanych danych.
- Monitoruj metryki wydajności i skaluj konfiguracje magazynu w górę zgodnie z potrzebami. Ssd w warstwie Premium w wersji 2 umożliwia klientom skalowanie liczby operacji we/wy na sekundę i przepływności zgodnie z potrzebami na żądanie.
- Ważne jest regularne monitorowanie i analizowanie metryk wydajności w celu zidentyfikowania przyczyny ograniczeń liczby operacji we/wy na sekundę i podjęcia odpowiednich akcji w celu zoptymalizowania wydajności magazynu dla maszyny wirtualnej SQL.
Napiwek
Regularne monitorowanie metryk wydajności, dostrajanie operacji transferu danych i optymalizowanie konfiguracji dysków gwarantuje, że wydajność dysku danych dla maszyny wirtualnej SQL pozostaje optymalna bez przekraczania limitów.
Najlepsze rozwiązania dotyczące operacji we/wy
Ponieważ słabo skonfigurowane systemy magazynowania mogą prowadzić do problemów z wydajnością, możesz użyć okienka Magazyn w witrynie Azure Portal, aby uruchomić podzbiór reguł oceny najlepszych rozwiązań SQL specyficznych dla dysku, aby zidentyfikować problemy z konfiguracją magazynu z programem SQL Server na maszynach wirtualnych platformy Azure. Funkcja najlepszych rozwiązań SQL jest oparta na interfejsie API oceny SQL.
Pełną listę zaleceń można wyświetlić w witrynie GitHub. Filtrując kolumnę id w regułach w usłudze GitHub, możesz zobaczyć reguły konfiguracji dysku maszyny wirtualnej SQL, które są weryfikowane na karcie Najlepsze rozwiązania dotyczące konfiguracji we/wy okienka Magazyn dla zasobu maszyn wirtualnych SQL w witrynie Azure Portal.
- AzSqlVmSize
- AzDataDiskCache
- AzDataDiskStriping
- AzDataOnDataDisks
- AzDbDefaultLocation
- AzDiskColumnCount
- AzErrorLogLocation
- AzPremSsdDataFiles
- AzTempDbFileLocation
- AzTranLogDiskCache
- NtfsBlockSizeNotFormatted
- LockedPagesInMemory
Na karcie Najlepsze rozwiązania dotyczące operacji we/wy użyj polecenia Uruchom ocenę, aby rozpocząć ocenę konfiguracji, która powinna potrwać kilka minut (chyba że istnieje duża liczba baz danych i obiektów). Alternatywnie, jeśli zobaczysz znacznik czasu dla najnowszych dostępnych wyników, możesz użyć opcji Pobierz najnowsze wyniki , aby przejrzeć wyniki z poprzednich ocen.
Analizowanie operacji we/wy przy użyciu programu PowerShell
Możesz również użyć skryptu programu PowerShell analizy we/wy, aby przeanalizować wydajność operacji we/wy maszyny wirtualnej z programem SQL Server:
# 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×pan=$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."
}
Następne kroki
- Uruchom ocenę najlepszych rozwiązań SQL, aby zidentyfikować potencjalne błędy konfiguracji, które mogą prowadzić do problemów z wydajnością.