Análisis de rendimiento de E/S (versión preliminar): SQL Server en máquinas virtuales de Azure

Artículo
05/22/2024

Se aplica a: SQL Server en máquina virtual de Azure

En este artículo se enseña a analizar el rendimiento de E/S de SQL Server en Azure Virtual Machines (VM) para encontrar problemas que resultan de superar los límites de máquinas virtuales y discos de datos.

Nota:

El análisis de E/S para SQL Server en máquinas virtuales de Azure en Azure Portal está actualmente en versión preliminar.

Información general

Aunque varias herramientas le ayudan a solucionar problemas de rendimiento de SQL Server, para hacerlo de forma eficaz en una máquina virtual de Azure, es importante comprender lo que sucede en el nivel de host y en la instancia de SQL Server donde, a menudo, correlacionar las métricas de host con cargas de trabajo de SQL Server puede ser un desafío. SQL Server en máquinas virtuales de Azure facilita la identificación de problemas de rendimiento derivados de IOPS (entrada/salida por segundo) y la limitación de rendimiento causada por superar los límites de máquinas virtuales y discos de datos.

Las métricas de rendimiento que muestran el problema y los posibles pasos para solucionarlo están disponibles en Azure Portal y se pueden consultar con la CLI de Azure.

El panel Almacenamiento del recurso de máquinas virtuales SQL en Azure Portal le ayuda con las siguientes tareas:

Administración de la configuración de almacenamiento
Identificación de la limitación de E/S
Evaluación del sistema para procedimientos recomendados relacionados con E/S

Descripción de las métricas

La pestaña Análisis de E/S se basa en métricas de Azure para identificar la latencia de disco y la limitación de E/S de disco o máquina virtual. Las métricas de Azure se muestrean cada 30 segundos y se agregan en un minuto.

El sistema supervisa la limitación y la latencia de disco. Se espera una limitación y se ignora a menos que también haya latencia de disco. Si se observan más de 500 milisegundos de latencia de disco en un periodo consecutivo de 5 minutos, el sistema:

Profundiza más en las métricas de rendimiento
Identifica el recurso limitado
Proporciona posibles causas principales y pasos de mitigación

En la tabla siguiente se explican las métricas de Azure que se usan para identificar asuntos de limitación problemáticos:

Métrica de Azure	Descripción de la métrica	Condición problemática	Conclusiones de limitación de E/S
Latencia de disco (versión preliminar)	Tiempo medio para completar las E/S del disco de datos durante el periodo de supervisión. Los valores se expresan en milisegundos.	> 500 milisegundos en un periodo consecutivo de 5 minutos	Hay un problema de latencia para que el sistema investigue aún más la posible limitación.
Porcentaje de IOPS en caché de VM consumido	el porcentaje calculado por la IOPS total completado con respecto al límite máximo de IOPS de máquinas virtuales en caché.	>= 95 % en un periodo consecutivo de 5 minutos	Hay limitación de máquinas virtuales. La aplicación que se ejecuta en la máquina virtual con SQL usa completamente la capacidad máxima de IOPS almacenada en caché disponible para la máquina virtual: las demandas de almacenamiento de la aplicación superan las IOPS almacenadas en caché proporcionadas por la configuración de almacenamiento subyacente de la máquina virtual.
Porcentaje de consumo de ancho de banda en caché de máquinas virtuales	el porcentaje calculado por el rendimiento total de disco completado en el límite máximo del rendimiento de las máquinas virtuales almacenadas en caché.	>= 95 % en un periodo consecutivo de 5 minutos	Hay limitación de máquinas virtuales. La aplicación que se ejecuta en la máquina virtual con SQL usa el ancho de banda máximo de disco almacenado en caché disponible para la transferencia de datos: las demandas de transferencia de datos de la aplicación superan los recursos de ancho de banda almacenados en caché proporcionados por la configuración de almacenamiento subyacente de la máquina virtual.
Porcentaje de IOPS no almacenado en caché de VM consumido	el porcentaje calculado por la IOPS total de una máquina virtual completado en el límite máximo de IOPS de máquinas virtuales que no se encuentran almacenadas en caché.	>= 95 % en un periodo consecutivo de 5 minutos	Hay limitación de máquinas virtuales. La aplicación que se ejecuta en la máquina virtual con SQL usa la capacidad máxima de IOPS no almacenada en caché disponible para la máquina virtual: las demandas de almacenamiento de la aplicación superan los recursos de IOPS no almacenados en caché proporcionados por la configuración de almacenamiento subyacente de la máquina virtual.
Porcentaje de consumo de ancho de banda que no está almacenado en caché de máquinas virtuales	el porcentaje calculado por el rendimiento total de disco de una máquina virtual completado en el límite máximo del rendimiento de las máquinas virtuales aprovisionadas.	>= 95 % en un periodo consecutivo de 5 minutos	Hay limitación de máquinas virtuales. La aplicación que se ejecuta en la máquina virtual con SQL usa el ancho de banda máximo de disco no almacenado en caché disponible para la transferencia de datos: las demandas de transferencia de datos de la aplicación superan los recursos de ancho de banda no almacenados en caché proporcionados por la configuración de almacenamiento subyacente de la máquina virtual.
Porcentaje de IOPS de disco de datos consumido	el porcentaje calculado por la IOPS de disco de datos completada con respecto a la IOPS del disco de datos aprovisionado.	>= 95 % en un periodo consecutivo de 5 minutos	Hay limitación del disco de datos. La aplicación que se ejecuta en la máquina virtual con SQL alcanza el límite de IOPS para el disco de datos aprovisionado: las demandas de almacenamiento de la aplicación superan las funcionalidades de rendimiento de la configuración de disco elegida.
Porcentaje de ancho de banda consumido de disco de datos	el porcentaje calculado por el rendimiento de disco de datos completado con respecto al rendimiento del disco de datos aprovisionado.	>= 95 % en un periodo consecutivo de 5 minutos	Hay limitación del disco de datos. La aplicación que se ejecuta en la máquina virtual con SQL alcanza el límite de IOPS para el disco de datos aprovisionado: las demandas de almacenamiento de la aplicación superan las funcionalidades de rendimiento de la configuración de disco elegida.

Resultados del análisis de E/S

En función de su análisis de métricas de rendimiento en las últimas 24 horas, el análisis de E/S determina que:

No hay ninguna limitación
Hay limitación de E/S a nivel de VM
Hay limitación de E/S a nivel de disco

No hay ningún problema de limitación de E/S

Si experimenta un problema de rendimiento, pero no hay latencia de disco, el problema de rendimiento no se debe a un problema de limitación de E/S. Deberá investigar otras áreas. Puede usar la lista de comprobación de procedimientos recomendados para SQL Server en máquinas virtuales de Azure para asegurarse de que el sistema está configurado de forma eficaz o encontrar vínculos útiles para solucionar problemas de rendimiento de SQL Server. Si habilita la característica de valoración de procedimientos recomendados de SQL, puede ver la lista completa de recomendaciones para la máquina virtual con SQL Server.

Problema de limitación de E/S a nivel de VM

Azure Virtual Machines son recursos informáticos basados en la nube que se incluyen en diferentes series y tamaños para varias cargas de trabajo, cada una con distintas funcionalidades y características de rendimiento. En el caso de las cargas de trabajo de SQL Server, por lo general, la serie recomendada para cargas de trabajo de SQL Server son las optimizadas para memoria, como la serie Ebdsv5, M y Mv2.

El tamaño de la máquina virtual determina el número de vCPU, memoria y almacenamiento disponibles para la instancia de SQL Server. En comparación con el almacenamiento, es relativamente fácil que los clientes cambien el tamaño de sus máquinas virtuales y escalen y reduzcan verticalmente su máquina virtual en función de las necesidades de recursos de la aplicación. Dado que es posible que las IOPS y el rendimiento se limiten en el nivel de máquina virtual, elija un tamaño de máquina virtual adecuado en función de las necesidades de rendimiento y el costo de la carga de trabajo.

Si va a migrar a Azure, puede usar herramientas como Data Migration Assistant y Recomendaciones de SKU para analizar la configuración y el uso actuales de SQL Server y sugerir el mejor tamaño de máquina virtual para la carga de trabajo en Azure.

Las siguientes métricas de Azure se usan para determinar que la carga de trabajo se limita a partir de los límites que impone la máquina virtual:

Porcentaje de consumo de IOPS en caché de la máquina virtual
Porcentaje de consumo de ancho de banda en caché de máquinas virtuales
Porcentaje de consumo de IOPS que no están almacenados en el caché de la máquina virtual
Porcentaje de consumo de ancho de banda que no está almacenado en caché de máquinas virtuales

Tenga en cuenta los siguientes puntos clave sobre la limitación de máquinas virtuales:

Puede aumentar la memoria, los núcleos virtuales, el rendimiento e IOPS mediante el cambio de tamaño de la máquina virtual dentro de una serie de máquinas virtuales.
No se puede reducir el tamaño de la máquina virtual a un nivel en el que el número de discos de datos supera el límite máximo de discos de datos para el tamaño de máquina virtual de destino.
Es importante determinar el patrón de limitación. Por ejemplo, es probable que se solucionen picos poco frecuentes de limitación mediante el ajuste de la carga de trabajo, mientras que los picos sostenidos podrían indicar que el almacenamiento subyacente no es capaz de controlar la carga de trabajo.

Problema de limitación de E/S a nivel de disco

En el caso de los clientes de máquinas virtuales SQL, el almacenamiento es el aspecto más crítico para configurarse adecuadamente para optimizar el rendimiento, ya que modificar el almacenamiento es más difícil que cambiar el tamaño de una máquina virtual. Por ejemplo, realizar cambios para aumentar la IOPS o el rendimiento de los discos SSD prémium requiere la creación de un nuevo grupo de almacenamiento. Por lo tanto, es fundamental optimizar la configuración de almacenamiento para el precio y el rendimiento durante la fase de planeación para evitar problemas de rendimiento después de la implementación.

Las siguientes métricas de Azure se usan para determinar que la carga de trabajo se limita a partir de los límites que impone el disco:

Porcentaje de consumo de IOPS de disco de datos
Porcentaje de consumo de ancho de banda del disco de datos Tenga en cuenta los siguientes puntos clave sobre la limitación de E/S de nivel de disco:
El disco de datos es fundamental para el rendimiento de SQL Server. Se recomienda colocar archivos de datos de SQL Server (.mdf) y de registro (.df) en el disco de datos.
Para limitar el nivel de disco de datos, habilite el almacenamiento en caché de lectura, si está disponible.

Porcentaje de consumo de IOPS de disco de datos

La métrica de porcentaje de consumo de IOPS del disco de datos mide el consumo de IOPS en el nivel de disco. Por lo general, las necesidades elevadas de IOPS están asociadas a cargas de trabajo y aplicaciones basadas en OLTP muy transaccionales.   Los siguientes escenarios o condiciones pueden superar potencialmente los límites de IOPS de disco de datos:

Carga de trabajo de transacciones elevadas (IOPS): si la aplicación está procesando un gran volumen de transacciones de base de datos que implican operaciones frecuentes de lectura y escritura, puede consumir rápidamente las IOPS asignadas. 
Consultas ineficaces: las consultas SQL mal optimizadas o las operaciones de recuperación de datos pueden provocar una actividad excesiva de E/S, lo que consume más IOPS de lo previsto. 
Usuarios simultáneos: si varios usuarios o sesiones acceden simultáneamente a la base de datos y generan solicitudes de E/S, el efecto acumulativo puede dar lugar a alcanzar el límite de IOPS. 
Recursos que compiten: si la infraestructura física subyacente se comparte en gran medida con otros inquilinos o cargas de trabajo, puede afectar a las IOPS disponibles para la máquina virtual. 
Picos temporales: los picos temporales en la carga de trabajo, como el procesamiento por lotes o las migraciones de datos, pueden provocar aumentos repentinos en la demanda de E/S que superan las IOPS asignadas. 
Tamaño de disco pequeño: si el tamaño del disco de datos aprovisionado es relativamente pequeño, la capacidad de IOPS podría estar limitada. Los discos individuales más pequeños tienen límites de IOPS más bajos y, si las demandas de la aplicación superan este límite, el "Porcentaje de consumo de IOPS del disco de datos" alcanza el 100 %. 
Tipo de disco insuficiente: elegir un tipo de disco de menor rendimiento (por ejemplo, un HDD estándar) para una aplicación con un uso intensivo de E/S puede dar lugar a limitaciones de IOPS. 
Tamaño de franja de disco no optimizado: si la configuración de almacenamiento no está optimizada para la carga de trabajo, podría provocar un rendimiento de IOPS poco óptimo.

Tenga en cuenta los pasos siguientes para evitar superar el límite de IOPS de disco de datos:

Optimice las consultas SQL y el diseño de bases de datos para minimizar las operaciones de E/S innecesarias. 
Elija un tipo de disco adecuado (SSD estándar o SSD prémium) que coincida con los requisitos de IOPS de la aplicación. 
Use tamaños de disco más grandes para aumentar la capacidad de IOPS disponible. 
Distribuya la E/S entre varios discos de datos mediante configuraciones RAID.

Porcentaje de consumo de ancho de banda del disco de datos

La métrica de Azure Porcentaje de consumo de ancho de banda del disco de datos mide el uso del ancho de banda en el nivel de disco. Por lo general, las necesidades de alto rendimiento están asociadas con el almacenamiento de datos, data mart, informes, ETL y otras cargas de trabajo de análisis de datos.

Los siguientes escenarios o condiciones pueden superar potencialmente los límites de ancho de banda del disco de datos:

Transferencias de datos grandes: las transferencias frecuentes de datos de aplicaciones a gran escala entre el disco y la base de datos SQL pueden consumir rápidamente el ancho de banda del disco de datos disponible. 
Carga masiva de datos: las actividades de transferencia de disco asociadas a inserciones de datos masivas, actualizaciones o importaciones pueden provocar un consumo elevado de ancho de banda. 
Almacenamiento o análisis de datos: las aplicaciones que implican intensos almacenamiento de datos, procesamiento de análisis o informes pueden generar un movimiento de datos considerable, lo que puede provocar que se superen los límites de ancho de banda.
Tecnología o replicación de alta redundancia de datos: la copia de datos asociada a usa la replicación basada en disco, la creación de reflejo de datos u otros mecanismos de redundancia pueden contribuir a la saturación del ancho de banda. 
Copias de seguridad y restauración de datos: las copias de seguridad de datos frecuentes, las instantáneas o los procesos de restauración pueden consumir un ancho de banda de disco de datos significativo. 
Ejecución de consultas paralelas: las consultas paralelas que implican exámenes o combinaciones de datos grandes pueden provocar un movimiento de datos considerable que dé lugar a un uso de ancho de banda. 
Tráfico de red elevado: una actividad de red elevada, como las transferencias de datos entre la máquina virtual y otros recursos, puede afectar indirectamente a la disponibilidad del ancho de banda del disco de datos. 
Tipo de disco insuficiente: elegir un tipo de disco de menor rendimiento para una aplicación con requisitos elevados de transferencia de datos puede dar lugar a superar el límite de ancho de banda. 
Operaciones simultáneas de uso intensivo de datos: el efecto combinado de varios procesos o sesiones simultáneos que acceden a datos y los transfieren en el mismo disco pueden dar lugar a alcanzar el límite de ancho de banda. 
Consultas no optimizadas o procesos ETL: las consultas SQL mal optimizadas o los procesos de extraer, transformar, cargar (ETL) pueden provocar un movimiento excesivo de datos que da lugar a un consumo excesivo de ancho de banda.

Tenga en cuenta los pasos siguientes para evitar superar el límite de ancho de banda del disco de datos:

Optimice las operaciones de transferencia de datos para minimizar el movimiento de datos innecesario. 
Considere la posibilidad de usar tipos de disco de mayor rendimiento que ofrecen mayor capacidad de ancho de banda, como SSD prémium o SSD prémium v2.
Distribuya datos entre varios discos mediante técnicas como la creación de particiones o el particionamiento.
Optimice y paralelice las consultas y el procesamiento de datos para reducir el movimiento de datos.
Use mecanismos de almacenamiento de datos eficaces y compresión para reducir el volumen de datos que se transfiere.
Supervise las métricas de rendimiento y escale verticalmente las configuraciones de almacenamiento según sea necesario. SSD prémium v2 permite a los clientes escalar sus IOPS y rendimiento según sea necesario a petición.
Es importante supervisar y analizar las métricas de rendimiento periódicamente para identificar la causa de las limitaciones de IOPS y realizar acciones adecuadas para optimizar el rendimiento del almacenamiento para la máquina virtual con SQL.

Sugerencia

La supervisión periódica de las métricas de rendimiento, el ajuste de las operaciones de transferencia de datos y la optimización de las configuraciones de disco garantiza que el rendimiento del disco de datos para la máquina virtual con SQL siga siendo óptimo sin superar los límites.

Dado que los sistemas de almacenamiento mal configurados pueden provocar problemas de rendimiento, puede usar el panel Almacenamiento en Azure Portal para ejecutar un subconjunto específico del disco de reglas de valoración de procedimientos recomendados de SQL para identificar problemas de configuración de almacenamiento con SQL Server en máquinas virtuales de Azure. La característica de procedimientos recomendados de SQL se basa en la API de SQL Assessment.

Puede ver una lista completa de recomendaciones en GitHub. Al filtrar por la columna id en las reglas de GitHub, puede ver las reglas de configuración del disco de máquina virtual con SQL que se validan en la pestaña Procedimientos recomendados de configuración de E/S del panel Almacenamiento para el recurso de máquinas virtuales con SQL en Azure Portal.

AzSqlVmSize
AzDataDiskCache
AzDataDiskStriping
AzDataOnDataDisks
AzDbDefaultLocation
AzDiskColumnCount

AzErrorLogLocation
AzPremSsdDataFiles
AzTempDbFileLocation
AzTranLogDiskCache
NtfsBlockSizeNotFormatted
LockedPagesInMemory

En la pestaña Procedimientos recomendados relacionados con E/S, use Ejecutar evaluación para iniciar una evaluación de la configuración, que debe tardar unos minutos en completarse (a menos que haya un gran número de bases de datos y objetos). Como alternativa, si ve una marca de tiempo para obtener los resultados disponibles más recientes, puede usar Capturar resultados más recientes para revisar los resultados de las evaluaciones anteriores.

Análisis de E/S con PowerShell

También puede usar el script de PowerShell de análisis de E/S para analizar el rendimiento de E/S de VM con 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&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."
}

Pasos siguientes

Ejecute una valoración de procedimientos recomendados de SQL para identificar posibles configuraciones erróneas que podrían provocar problemas de rendimiento.

Compartir a través de