Bagikan melalui


Analisis Performa I/O (Pratinjau) - SQL Server di Azure VM

Berlaku untuk: SQL Server di Azure VM

Artikel ini mengajarkan Anda untuk menganalisis performa I/O untuk SQL Server di Azure Virtual Machines (VM) untuk menemukan masalah yang dihasilkan dari melebihi batas komputer virtual dan disk data.

Catatan

Analisis I/O untuk SQL Server di Komputer Virtual Azure di portal Azure saat ini dalam pratinjau.

Gambaran Umum

Meskipun berbagai alat membantu Anda memecahkan masalah performa SQL Server, untuk melakukannya secara efektif pada Azure VM, penting untuk memahami apa yang terjadi di tingkat host dan instans SQL Server Anda di mana, sering kali, menghubungkan metrik host dengan beban kerja SQL Server dapat menjadi tantangan. SQL Server di Azure VM memudahkan untuk mengidentifikasi masalah performa yang berasal dari IOPS (Input/ Output per detik) dan pembatasan throughput yang disebabkan oleh melebihi batas komputer virtual dan disk data.

Metrik performa yang menunjukkan masalah, dan langkah-langkah potensial untuk mengatasinya, tersedia di portal Azure, dan dapat dikueri dengan Azure CLI.

Panel Penyimpanan sumber daya komputer virtual SQL Anda di portal Azure membantu Anda:

Memahami metrik

Tab Analisis I/O bergantung pada Metrik Azure untuk mengidentifikasi latensi disk, dan pembatasan I/O VM atau disk. Metrik Azure diambil sampelnya setiap 30 detik dan diagregasi menjadi satu menit.

Sistem memantau pembatasan dan latensi disk. Beberapa pembatasan diharapkan, dan diabaikan kecuali ada juga latensi disk. Jika lebih dari 500 milidetik latensi disk diamati dalam periode 5 menit berturut-turut, maka sistem:

  • Menggali lebih dalam metrik performa
  • Mengidentifikasi sumber daya yang dibatasi
  • Menyediakan potensi akar penyebab dan langkah-langkah mitigasi

Tabel berikut menjelaskan Metrik Azure yang digunakan untuk mengidentifikasi masalah pembatasan yang bermasalah:

Metrik Azure Deskripsi metrik Kondisi bermasalah Kesimpulan pembatasan I/O
Latensi disk (pratinjau) Waktu rata-rata untuk menyelesaikan IO untuk disk data selama periode yang dipantau. Nilai dalam milidetik. > 500 milidetik dalam periode 5 menit berturut-turut Ada masalah latensi bagi sistem untuk menyelidiki lebih lanjut potensi pembatasan.
Persentase Yang Dikonsumsi IOPS Cache VM Persentase yang dihitung dengan total IOPS yang diselesaikan selama batas IOPS komputer virtual maksimum yang di-cache. >= 95% dalam periode 5 menit berturut-turut Ada pembatasan VM. Aplikasi yang berjalan pada komputer virtual SQL sepenuhnya menggunakan kapasitas IOPS cache maksimum yang tersedia untuk komputer virtual - tuntutan penyimpanan aplikasi melebihi IOPS cache yang disediakan oleh konfigurasi penyimpanan yang mendasar komputer virtual.
Persentase Penggunaan Bandwidth Cache VM Persentase yang dihitung oleh total throughput disk yang diselesaikan melalui throughput komputer virtual maksimum yang di-cache. >= 95% dalam periode 5 menit berturut-turut Ada pembatasan VM. Aplikasi yang berjalan pada komputer virtual SQL menggunakan bandwidth disk cache maksimum yang tersedia untuk transfer data - tuntutan transfer data aplikasi melebihi sumber daya bandwidth yang di-cache yang disediakan oleh konfigurasi penyimpanan dasar komputer virtual. 
VM Uncached IOPS Consumed Percentage Persentase yang dihitung oleh total IOPS pada komputer virtual yang diselesaikan selama batas IOPS komputer virtual maks yang tidak di-cache. >= 95% dalam periode 5 menit berturut-turut Ada pembatasan VM. Aplikasi yang berjalan pada Komputer virtual SQL menggunakan kapasitas IOPS maksimum yang tidak diperbolehkan yang tersedia untuk komputer virtual - tuntutan penyimpanan aplikasi melebihi sumber daya IOPS yang tidak di-cache yang disediakan oleh konfigurasi penyimpanan yang mendasari komputer virtual.
Persentase Penggunaan Bandwidth Yang Tidak Di-cache VM Persentase yang dihitung oleh total throughput disk pada komputer virtual yang diselesaikan melalui throughput komputer virtual maksimum yang disediakan. >= 95% dalam periode 5 menit berturut-turut Ada pembatasan VM. Aplikasi yang berjalan pada komputer virtual SQL menggunakan bandwidth disk maksimum yang tidak diperbolehkan untuk transfer data – tuntutan transfer data aplikasi melebihi sumber daya bandwidth yang tidak di-cache yang disediakan oleh konfigurasi penyimpanan yang mendasari komputer virtual.
Persentase Penggunaan IOPS Disk Data Persentase yang dihitung oleh IOPS disk data selesai melalui IOPS disk data yang disediakan. >= 95% dalam periode 5 menit berturut-turut Ada pembatasan disk data. Aplikasi yang berjalan pada komputer virtual SQL mencapai batas IOPS untuk disk data yang disediakan - tuntutan penyimpanan aplikasi melebihi kemampuan performa konfigurasi disk yang dipilih.
Persentase Penggunaan Bandwidth Disk Data Persentase yang dihitung oleh throughput disk data selesai melalui throughput disk data yang disediakan. >= 95% dalam periode 5 menit berturut-turut Ada pembatasan disk data. Aplikasi yang berjalan pada komputer virtual SQL mencapai batas IOPS untuk disk data yang disediakan - tuntutan penyimpanan aplikasi melebihi kemampuan performa konfigurasi disk yang dipilih.

Temuan analisis I/O

Berdasarkan analisis metrik performanya dalam 24 jam terakhir, analisis I/O menentukan bahwa ada:

  • Tidak ada pembatasan
  • Pembatasan I/O tingkat VM
  • Pembatasan I/O tingkat disk

Tidak ada masalah pembatasan I/O

Jika Anda mengalami masalah performa tetapi tidak ada latensi disk, maka masalah performa bukan karena masalah pembatasan I/O. Anda harus menyelidiki area lain. Anda dapat menggunakan daftar periksa Praktik terbaik untuk SQL Server di Azure VM untuk memastikan sistem Anda dikonfigurasi secara efisien, atau menemukan tautan yang berguna untuk memecahkan masalah performa SQL Server. Jika Anda mengaktifkan fitur penilaian praktik terbaik SQL, Anda dapat melihat daftar lengkap rekomendasi untuk komputer virtual SQL Server Anda.

Masalah pembatasan I/O tingkat VM

Azure Virtual Machines adalah sumber daya komputasi berbasis cloud yang hadir dalam berbagai seri dan ukuran untuk berbagai beban kerja, masing-masing dengan kemampuan dan karakteristik performa yang berbeda. Untuk beban kerja SQL Server, umumnya, seri yang direkomendasikan untuk beban kerja SQL Server adalah yang dioptimalkan memori, seperti seri Ebdsv5, M, dan Mv2.

Ukuran VM menentukan jumlah vCPU, memori, dan penyimpanan yang tersedia untuk instans SQL Server. Dibandingkan dengan penyimpanan, relatif mudah bagi pelanggan untuk mengubah ukuran komputer virtual mereka dan menskalakan VM mereka naik dan turun berdasarkan kebutuhan sumber daya aplikasi. Karena dimungkinkan bagi IOPS dan throughput untuk dibatasi pada tingkat VM, pilih ukuran VM yang sesuai berdasarkan kebutuhan performa dan biaya beban kerja.

Jika Anda bermigrasi ke Azure, Anda dapat menggunakan alat seperti Asisten Migrasi Data dan Rekomendasi SKU, untuk menganalisis konfigurasi dan penggunaan SQL Server Anda saat ini dan menyarankan ukuran VM terbaik untuk beban kerja Anda di Azure.

Metrik Azure berikut digunakan untuk menentukan beban kerja dibatasi dari melebihi batas yang diberlakukan oleh VM:

  • Persentase Pemakaian IOPS yang Di-cache VM
  • Persentase Pemakaian Bandwidth Cached VM
  • Persentase Pemakaian IOPS yang Tidak Di-cache VM
  • Persentase Pemakaian Bandwidth yang Tidak Di-cache VM

Pertimbangkan poin-poin penting berikut tentang pembatasan VM:

  • Anda dapat meningkatkan memori, vCore, throughput, dan IOPS dengan mengubah ukuran komputer virtual Anda dalam seri VM.
  • Anda tidak dapat mengurangi ukuran VM ke tingkat di mana jumlah disk data melebihi batas disk data maksimum untuk ukuran VM target.
  • Penting untuk menentukan pola pembatasan. Misalnya, lonjakan pembatasan yang jarang muncul kemungkinan dapat diatasi dengan menyetel beban kerja, sedangkan lonjakan berkelanjutan dapat menunjukkan penyimpanan yang mendasarinya tidak dapat menangani beban kerja.

Masalah pembatasan I/O tingkat disk

Untuk pelanggan komputer virtual SQL, penyimpanan adalah aspek paling penting untuk dikonfigurasi dengan tepat untuk performa yang dioptimalkan karena memodifikasi penyimpanan lebih menantang daripada mengubah ukuran komputer virtual. Misalnya, membuat perubahan apa pun untuk meningkatkan IOPS atau throughput untuk disk SSD Premium mengharuskan pembuatan kumpulan penyimpanan baru. Dengan demikian, sangat penting untuk mengoptimalkan konfigurasi penyimpanan untuk harga dan performa selama fase perencanaan untuk menghindari masalah performa setelah penyebaran.

Metrik Azure berikut digunakan untuk menentukan beban kerja dibatasi dari melebihi batas yang diberlakukan oleh disk:

  • Persentase IOPS Disk Data yang Digunakan

  • Persentase Penggunaan Bandwidth Disk Data Pertimbangkan poin utama berikut tentang pembatasan I/O tingkat disk:

  • Disk data sangat penting untuk performa SQL Server. Menempatkan file data SQL Server (.mdf) dan log (.df) pada disk data disarankan.

  • Untuk pembatasan di tingkat disk data, aktifkan read-caching, jika tersedia.

Persentase IOPS Disk Data yang Digunakan

Metrik Persentase Penggunaan IOPS Disk Data mengukur konsumsi IOPS di tingkat disk. Umumnya, kebutuhan IOPS yang tinggi dikaitkan dengan aplikasi dan beban kerja berbasis OLTP yang sangat transaksi.   Skenario atau kondisi berikut berpotensi melebihi batas IOPS disk data:

  • Beban Kerja Transaksi Tinggi (IOPS): Jika aplikasi memproses volume transaksi database tinggi yang melibatkan operasi baca dan tulis yang sering, aplikasi dapat dengan cepat menggunakan IOPS yang dialokasikan. 
  • Kueri yang tidak efisien: Kueri SQL yang dioptimalkan dengan buruk atau operasi pengambilan data dapat menyebabkan aktivitas I/O yang berlebihan, mengonsumsi lebih banyak IOPS daripada yang diantisipasi. 
  • Pengguna Bersamaan: Jika beberapa pengguna atau sesi secara bersamaan mengakses database dan menghasilkan permintaan I/O, efek kumulatif dapat mengakibatkan mencapai batas IOPS. 
  • Sumber Daya yang Bersaing: Jika infrastruktur fisik yang mendasar banyak dibagikan dengan penyewa atau beban kerja lain, itu dapat memengaruhi IOPS yang tersedia untuk komputer virtual Anda. 
  • Lonjakan Sementara: Lonjakan sementara beban kerja, seperti pemrosesan batch atau migrasi data, dapat menyebabkan peningkatan permintaan I/O yang tiba-tiba melampaui IOPS yang dialokasikan. 
  • Ukuran disk kecil: Jika ukuran disk data yang disediakan relatif kecil, kapasitas IOPS mungkin terbatas. Disk individu yang lebih kecil memiliki batas IOPS yang lebih rendah, dan jika tuntutan aplikasi melebihi batas ini, "Persentase Konsumsi IOPS Disk Data" mencapai 100%. 
  • Jenis disk yang tidak memadai: Memilih jenis disk berkinerja lebih rendah (seperti HDD Standar) untuk aplikasi intensif I/O dapat menyebabkan keterbatasan IOPS. 
  • Ukuran garis disk yang tidak optimal: Jika konfigurasi penyimpanan tidak dioptimalkan untuk beban kerja, hal ini dapat menyebabkan performa IOPS suboptimal. 

Pertimbangkan langkah-langkah berikut untuk menghindari melebihi batas IOPS disk data:

  • Optimalkan kueri SQL dan desain database untuk meminimalkan operasi I/O yang tidak perlu. 
  • Pilih jenis disk yang sesuai (SSD Standar atau SSD Premium) yang sesuai dengan persyaratan IOPS aplikasi Anda. 
  • Gunakan ukuran disk yang lebih besar untuk meningkatkan kapasitas IOPS yang tersedia. 
  • Distribusikan I/O di beberapa disk data menggunakan konfigurasi RAID. 

Persentase Penggunaan Bandwidth Disk Data

Metrik Data Disk Bandwidth Consumed Percentage Azure mengukur pemanfaatan bandwidth di tingkat disk. Umumnya, kebutuhan throughput tinggi dikaitkan dengan pergudangan data, data mart, pelaporan, ETL, dan beban kerja analitik data lainnya.

Skenario atau kondisi berikut berpotensi melebihi batas bandwidth disk data:

  • Transfer data besar: Transfer data aplikasi skala besar yang sering antara disk dan database SQL, dapat dengan cepat menggunakan bandwidth disk data yang tersedia. 
  • Pemuatan data massal: Aktivitas transfer disk yang terkait dengan penyisipan data massal, pembaruan, atau impor, dapat menyebabkan konsumsi bandwidth tinggi. 
  • Pergudangan atau analitik data: Aplikasi yang melibatkan pergudangan data berat, pemrosesan analitik, atau pelaporan dapat menghasilkan pergerakan data yang substansial, berpotensi menyebabkan melebihi batas bandwidth.
  • Teknologi/replikasi redundansi data tinggi: Penyalinan data yang terkait dengan penggunaan replikasi berbasis disk, pencerminan data, atau mekanisme redundansi lainnya dapat berkontribusi pada saturasi bandwidth. 
  • Pencadangan dan pemulihan data: Pencadangan data, rekam jepret, atau proses pemulihan yang sering dapat menggunakan bandwidth disk data yang signifikan. 
  • Eksekusi kueri paralel: Kueri paralel yang melibatkan pemindaian atau gabungan data besar dapat menyebabkan pergerakan data substansial yang menghasilkan pemanfaatan bandwidth. 
  • Lalu lintas jaringan yang ditingkatkan: Aktivitas jaringan tinggi, seperti transfer data antara komputer virtual dan sumber daya lainnya, secara tidak langsung dapat memengaruhi ketersediaan bandwidth disk data. 
  • Jenis disk yang tidak memadai: Memilih jenis disk berkinerja lebih rendah untuk aplikasi dengan persyaratan transfer data yang tinggi dapat menyebabkan melebihi batas bandwidth. 
  • Operasi intensif data bersamaan: Efek gabungan dari beberapa proses atau sesi bersamaan yang mengakses dan mentransfer data pada disk yang sama dapat mengakibatkan mencapai batas bandwidth. 
  • Kueri yang tidak optimal atau proses ETL: Kueri SQL yang dioptimalkan dengan buruk atau proses Ekstrak, Transformasi, Muat (ETL) dapat menyebabkan pergerakan data berlebihan yang menghasilkan konsumsi bandwidth yang berlebihan. 

Pertimbangkan langkah-langkah berikut untuk menghindari melebihi batas bandwidth disk data:

  • Optimalkan operasi transfer data untuk meminimalkan pergerakan data yang tidak perlu. 
  • Pertimbangkan untuk menggunakan jenis disk berkinerja lebih tinggi yang menawarkan kapasitas bandwidth yang lebih besar, seperti Premium SSD atau Premium SSD v2.
  • Mendistribusikan data di beberapa disk menggunakan teknik seperti pemartisian atau sharding.
  • Optimalkan dan paralelkan kueri dan pemrosesan data untuk mengurangi pergerakan data.
  • Gunakan kompresi dan mekanisme penyimpanan data yang efisien untuk mengurangi volume data yang ditransfer.
  • Pantau metrik performa dan tingkatkan konfigurasi penyimpanan Anda sesuai kebutuhan. Premium SSD v2 memungkinkan pelanggan untuk menskalakan IOPS dan throughput sesuai kebutuhan.
  • Penting untuk memantau dan menganalisis metrik performa secara teratur untuk mengidentifikasi penyebab keterbatasan IOPS dan mengambil tindakan yang sesuai untuk mengoptimalkan performa penyimpanan untuk komputer virtual SQL Anda.

Tip

Memantau metrik performa secara teratur, menyetel operasi transfer data, dan mengoptimalkan konfigurasi disk memastikan performa disk data Anda untuk komputer virtual SQL Anda tetap optimal tanpa melebihi batas.

Karena sistem penyimpanan yang dikonfigurasi dengan buruk dapat menyebabkan masalah performa, Anda dapat menggunakan panel Penyimpanan di portal Azure untuk menjalankan subset khusus disk aturan penilaian praktik terbaik SQL untuk mengidentifikasi masalah konfigurasi penyimpanan dengan SQL Server Anda di Azure VM. Fitur praktik terbaik SQL didasarkan pada SQL Assessment API.

Anda dapat melihat daftar lengkap rekomendasi di GitHub. Dengan memfilter kolom id pada aturan di GitHub, Anda dapat melihat aturan konfigurasi disk SQL VM yang divalidasi pada tab praktik terbaik konfigurasi I/O di panel Penyimpanan untuk sumber daya komputer virtual SQL Anda di portal Azure.

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

Pada tab praktik terbaik terkait I/O, gunakan Jalankan penilaian untuk memulai penilaian konfigurasi Anda, yang harus memakan waktu beberapa menit untuk diselesaikan (kecuali ada sejumlah besar database dan objek). Atau, jika Anda melihat tanda waktu untuk hasil terbaru yang tersedia, Anda dapat menggunakan Ambil hasil terbaru untuk meninjau temuan dari penilaian sebelumnya.

Menganalisis I/O dengan PowerShell

Anda juga dapat menggunakan skrip I/O Analysis PowerShell untuk menganalisis performa I/O komputer virtual SQL Server Anda:

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

Langkah berikutnya

  • Jalankan penilaian praktik terbaik SQL untuk mengidentifikasi potensi kesalahan konfigurasi yang dapat menyebabkan masalah performa.