Compartir a través de

Diagnóstico de la solución de problemas de rendimiento de Hiperescala de SQL

  • Artículo

Se aplica a:Azure SQL Database

Para solucionar problemas de rendimiento en una base de datos de Hiperescala, las metodologías generales de optimización del rendimiento de SQL son el punto de partida de cualquier investigación de rendimiento. Sin embargo, dada la arquitectura distribuida de Hiperescala, es posible que deban considerarse datos de diagnóstico adicionales. En este artículo se describen los datos de diagnóstico específicos de Hiperescala.

Esperas de velocidad de registro reducidas

Cada base de datos y grupo elástico en Azure SQL Database controla la tasa de generación de registros mediante control de la tasa de generación de registros. En Hiperescala, el límite de gobernanza de velocidad de registros se establece en 105 MB/s, independientemente del tamaño de proceso. Este valor se expone en la columna primary_max_log_rate de sys.dm_user_db_resource_governance.

En ocasiones, la tasa de generación de registros en la réplica de proceso principal debe reducirse para mantener los acuerdos de nivel de servicio de recuperabilidad. Por ejemplo, esto puede ocurrir cuando un servidor de páginas de u otra réplica de proceso está significativamente retrasado en la aplicación de nuevos registros de log desde el servicio de registro. Si no hay componentes de Hiperescala subyacentes, el mecanismo de gobernanza de velocidad de registro permite que la tasa de generación de registros alcance 100 MiB/s. Esta es la velocidad de generación de registros máxima efectiva en todos los tamaños de proceso de Hiperescala.

Nota

La tasa de generación de registros de 150 MiB/s está disponible como característica en vista previa (GB) opcional para la serie Premium y la memoria de la serie Premium optimizada. Para obtener más información y suscribirse a 150 MiB/s, consulte Blog: Mejoras de Hiperescala de noviembre de 2024.

Los siguientes tipos de espera aparecen en sys.dm_os_wait_stats cuando se reduce la tasa de registro:

Tipo de espera Motivo
RBIO_RG_STORAGE Consumo retrasado de logs por parte de un servidor de páginas
RBIO_RG_DESTAGE Retraso en el consumo de registros por el almacenamiento de registros a largo plazo
RBIO_RG_REPLICA Consumo de registros retrasado por una réplica secundaria de HA o una réplica denominada
RBIO_RG_GEOREPLICA Consumo de registros retrasado por una réplica secundaria geográfica
RBIO_RG_DESTAGE Consumo retrasado del registro por parte del servicio de registro
RBIO_RG_LOCALDESTAGE Consumo retrasado del registro por parte del servicio de registro
RBIO_RG_STORAGE_CHECKPOINT Retraso en el consumo de registros en un servidor de páginas debido a un punto de control de base de datos lento
RBIO_RG_MIGRATION_TARGET Consumo retrasado del registro por parte de la base de datos no hiperescalar durante la migración inversa

La función de administración dinámica (DMF) sys.dm_hs_database_log_rate() proporciona detalles adicionales para ayudarle a comprender la reducción de la velocidad de registro, si existe. Por ejemplo, puede indicarle qué réplica secundaria está específicamente retrasada en la aplicación de registros del log, y cuál es el tamaño total del log de transacciones que aún no se ha aplicado.

Lecturas del servidor de páginas

Las réplicas de proceso no almacenan en caché una copia completa de la base de datos de manera local. Los datos de la réplica de computación se almacenan en el grupo de búferes (en memoria) y en la caché de la extensión resistente del grupo de búferes local (RBPEX), que contiene un subconjunto de las páginas de datos a las que se accede con más frecuencia. Esta caché SSD local está dimensionada proporcionalmente al tamaño de cómputo. Por otro lado, cada servidor de páginas tiene una caché SSD completa para la parte de la base de datos que mantiene.

Cuando se emite una E/S de lectura en una réplica de proceso, si los datos no existen en el grupo de búferes o en la caché de SSD local, la página del número de secuencia de registro (LSN) solicitado se captura desde el servidor de páginas correspondiente. Las lecturas de los servidores de página son remotas y son más lentas que las lecturas de la caché SSD local. Al solucionar problemas de rendimiento relacionados con las operaciones de entrada/salida, necesitamos poder saber cuántas operaciones de IO se realizaron mediante las lecturas del servidor de páginas, que son relativamente más lentas.

Varias vistas administradas dinámicas (DMV) y eventos extendidos tienen columnas y campos que especifican el número de lecturas remotas de un servidor de páginas. Este número se puede comparar con el total de lecturas. Query Store también captura las lecturas del servidor de páginas en las estadísticas de tiempo de ejecución de consultas.

  • Las columnas para las lecturas del servidor de páginas de informes están disponibles en las DMV de ejecución y las vistas de catálogo:
  • Los campos de lectura del servidor de páginas están presentes en los siguientes eventos extendidos:
    • sql_statement_completed
    • sp_statement_completed
    • sql_batch_completed
    • rpc_completed
    • scan_stopped
    • query_store_begin_persist_runtime_stat
    • query_store_execution_runtime_info
  • Los atributos ActualPageServerReads/ActualPageServerReadAheads están presentes en el XML del plan de consulta para los planes que incluyen estadísticas en tiempo de ejecución. Por ejemplo: 
    <RunTimeCountersPerThread Thread="8" ActualRows="90466461" [...] ActualPageServerReads="0" ActualPageServerReadAheads="5687297" ActualLobPageServerReads="0" ActualLobPageServerReadAheads="0" />

    Sugerencia

    Para ver estos atributos en la ventana de propiedades del plan de consulta, necesitará SSMS 18.3 o posterior.

Estadísticas de archivos virtuales y cuentas de E/S

En Azure SQL Database, el DMF sys.dm_io_virtual_file_stats() es una manera de supervisar las estadísticas de E/S de base de datos, como IOPS, rendimiento y latencia. Las características de E/S en Hiperescala son diferentes debido a su arquitectura distribuida. En esta sección, nos centramos en la E/S de lectura y escritura, como se ve en este DMF. En Hiperescala, cada archivo de datos visible en esta DMF corresponde a un servidor de páginas. DMF también proporciona estadísticas de E/S del caché SSD local en la réplica de cálculo y del registro de transacciones.

Uso de caché de SSD local

Dado que la caché local de SSD se encuentra en la misma réplica de cálculo donde el motor de base de datos procesa consultas, la E/S en esta caché es más rápida que la E/S en los servidores de página. En una base de datos de Hiperescala o un grupo elástico, sys.dm_io_virtual_file_stats() tiene una fila especial que informa sobre estadísticas de E/S para la caché SSD local. Esta fila tiene el valor de 0 para las columnas database_id y file_id. Por ejemplo, la consulta siguiente devuelve las estadísticas de E/S de caché de SSD local desde el inicio de la base de datos.

SELECT *
FROM sys.dm_io_virtual_file_stats(0, NULL);

Una relación de lecturas de la caché SSD local en comparación con las lecturas agregadas de todos los demás archivos de datos es la proporción de aciertos de la caché SSD local. Los contadores de rendimiento RBPEX cache hit ratio y RBPEX cache hit ratio base proporcionan esta métrica y están disponibles en la DMV de sys.dm_os_performance_counters.

Lecturas de datos

  • Cuando el motor de base de datos emite las lecturas en una réplica de cómputo, pueden ser atendidas por la memoria caché SSD local, o por servidores de páginas de datos, o por una combinación de las dos si se leen varias páginas.
  • Cuando la réplica de proceso lee algunas páginas de un archivo de datos específico, por ejemplo, el archivo con file_id 1, si estos datos residen únicamente en la caché SSD local, toda la E/S de esta lectura se contabiliza en file_id 0. Si parte de esos datos se encuentra en la caché SSD local y otra parte está en servidores de página, la E/S se contabiliza hacia file_id 0 para la parte servida desde la caché SSD local, mientras que la parte servida desde los servidores de página se contabiliza en sus archivos correspondientes.
  • Cuando una réplica de computación solicita una página en un LSN determinado desde un servidor de páginas, si el servidor de páginas aún no ha alcanzado el LSN solicitado, la lectura en la réplica de computación espera hasta que el servidor de páginas alcance el LSN solicitado antes de que se devuelva la página. Para cualquier lectura de un servidor de páginas en la réplica de proceso, verá un tipo de espera de PAGEIOLATCH_* si está esperando esa E/S. En Hiperescala, este tiempo de espera incluye el tiempo necesario para capturar la página solicitada en el servidor de páginas en el LSN requerido y el tiempo necesario para transferir la página del servidor de páginas a la réplica de proceso.
  • Las lecturas grandes, como las lecturas anticipadas, a menudo se realizan mediante lecturas de recopilación de dispersión. Esto permite leer hasta 4 MB como una sola operación de E/S de lectura. Sin embargo, cuando los datos que se leen se encuentran en la caché SSD local, estas lecturas se contabilizan como lecturas individuales de 8 KB, ya que el grupo de búferes y la caché SSD local siempre usan páginas de 8 KB. Como resultado, el número de E/S de lectura que se observa en la caché de SSD local podría ser mayor que el número real de E/S que realiza el motor.

Escrituras de datos

  • La réplica de proceso principal no escribe directamente en los servidores de páginas. En su lugar, los registros del servicio de registro se reproducen en los servidores de páginas correspondientes.
  • Las escrituras en la réplica de cálculo son principalmente escrituras en la caché de SSD local (file_id 0). En el caso de las escrituras que tienen más de 8 KB, es decir, las realizadas con recopilación y escritura, cada operación de escritura se traduce en varias escrituras individuales de 8 KB en la caché SSD local, ya que el grupo de búferes y la caché SSD local siempre usan páginas de 8 KB. Como resultado, el número de E/S de escritura que se ven en la caché de SSD local podría ser mayor que el número real de E/S realizados por el motor.
  • Archivos de datos distintos de file_id 0 que corresponden a servidores de páginas también pueden mostrar registros. En Hyperscale, estas escrituras se simulan, ya que las réplicas de computación nunca escriben directamente en los servidores de páginas. Las estadísticas de E/S se contabilizan a medida que se producen en la réplica de computación. Las IOPS, el rendimiento y la latencia que se ven en una réplica de cómputo para archivos de datos, que no sean file_id 0, no reflejan las estadísticas reales de E/S de escrituras que se producen en los servidores de página.

Escrituras de registro

  • En la réplica de cálculo principal, se registra una escritura en el log en sys.dm_io_virtual_file_stats() bajo file_id 2.
  • A diferencia de los grupos de disponibilidad AlwaysOn, cuando una transacción se confirma en la réplica de proceso principal, los registros de registro no se protegen en la réplica secundaria. En Hiperescala, el registro se protege en el servicio de registro y se aplica a las réplicas secundarias de forma asincrónica. Dado que las escrituras de log no se producen realmente en réplicas secundarias, cualquier contabilización de las E/S de log en sys.dm_io_virtual_file_stats() en las réplicas secundarias no debe utilizarse como estadísticas de E/S del log de transacciones.

E/S de datos en estadísticas de uso de recursos

En una base de datos que no sea de Hiperescala, las IOPS de lectura y escritura combinadas con los archivos de datos, en relación con el límite de IOPS de datos de gobernanza de recursos, se muestran en las vistas sys. dm_db_resource_stats y sys. resource_stats, en la columna avg_data_io_percent. Las DMV correspondientes para grupos elásticos se sys.dm_elastic_pool_resource_stats y sys.elastic_pool_resource_stats. Los mismos valores se notifican como el porcentaje de E/S de datos de las métricas de Azure Monitor para bases de datos y grupos elásticos.

En una base de datos de hiperescala, estas columnas y métricas informan sobre el uso de IOPS de datos en relación con el límite para el almacenamiento SSD local solo en la réplica de cálculo, lo que incluye E/S en la caché SSD local y en la base de datos tempdb. Un valor del 100% en esta columna indica que la gobernanza de recursos está limitando las IOPS del almacenamiento local. Si esto se correlaciona con un problema de rendimiento, ajuste la carga de trabajo para generar menos E/S o aumente el tamaño de proceso para aumentar la gobernanza de recursos Máximo de IOPS de datoslímite. Para la gobernanza de recursos de las lecturas y escrituras de caché SSD locales, el sistema cuenta E/S individuales de 8 KB, en lugar de E/S más grandes que el motor de base de datos puede emitir.

La entrada/salida de datos en los servidores de páginas no se notifica en las vistas de uso de recursos ni a través de métricas de Azure Monitor, pero se reporta en sys.dm_io_virtual_file_stats() como se ha mencionado anteriormente.

Contenido relacionado