Compartir a través de

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

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. El límite de velocidad de registro se expone en la primary_max_log_rate columna 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 cumplir con los acuerdos de nivel de servicio (SLAs) 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 presentes, el mecanismo de gobernanza de la tasa de registros permite que la tasa de generación de registros alcance los 150 MiB/s por base de datos para el hardware optimizado para memoria de la serie premium y el hardware de la serie premium. Para el hardware de la serie estándar, la velocidad máxima del registro es de 100 MiB/s por base de datos. En el caso de los grupos elásticos, la velocidad máxima de registro es de 150 MiB/s por grupo para el hardware de la serie de gama Premium y optimizado para memoria, y 125 MiB/s por grupo para otros hardware.

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 más detalles para ayudarle a comprender la reducción de la tasa 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 cálculo 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 vistas de administración dinámica (DMVs) de ejecución y en 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.

Para Hiperescala, los datos pertinentes de sys.dm_io_virtual_file_stats() son los siguientes:

  • Las filas en las que el database_id valor coincide con el valor devuelto por la función DB_ID y donde el file_id valor es distinto de 2, corresponden a los servidores de páginas. Normalmente, cada fila corresponde a un servidor de páginas. Sin embargo, para archivos más grandes, se usan varios servidores de página.

    • La fila con file_id 2 corresponde al registro de transacciones.

  • Las filas en las que el valor de la database_id columna es 0 corresponden a la caché SSD local en la réplica de proceso.

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 filas especiales que notifican estadísticas de E/S para la caché de SSD local. Estas filas tienen el valor de 0 para la database_id columna. 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 proporción de las lecturas agregadas de los archivos de caché SSD local con las lecturas agregadas de todos los demás archivos de datos es la proporción de aciertos de caché de 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 los archivos de caché SSD locales donde database_id es 0. Si alguna parte de esos datos se encuentra en la memoria caché de SSD local y alguna parte está en los servidores de páginas, entonces la entrada/salida (E/S) se contabiliza parcialmente a los archivos de caché SSD locales y parcialmente a los archivos de datos correspondientes a los servidores de páginas.

  • Cuando una réplica de cálculo solicita una página en un LSN determinado desde un servicio de páginas, si el servicio de páginas aún no ha alcanzado el LSN solicitado, la lectura en la réplica de cálculo espera hasta que el servicio de páginas alcance el LSN requerido antes de que se devuelva la página. Para cualquier lectura de un servidor de almacenamiento de páginas en la réplica de procesamiento, verá un PAGEIOLATCH_* tipo de espera si está esperando esa I/O. 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 principal de cómputo 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 (database_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 database_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 de escritura, el rendimiento y la latencia observados en una réplica de cálculo para los archivos de datos, distintos de database_id 0, no reflejan las estadísticas reales de E/S de escritura que se producen en los servidores de página.

Escrituras de registro

  • En la réplica de cómputo principal, las escrituras en el registro se contabilizan en sys.dm_io_virtual_file_stats() bajo file_id 2.

  • A diferencia de los grupos de disponibilidad, cuando una transacción se confirma en la réplica de cálculo principal, los registros del log no se consolidan 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 no-Hiperescala, las IOPS combinadas de lectura y escritura contra archivos de datos en relación al límite de E/S de la gobernanza de recursos se notifican 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 Hyperscale, estas columnas y métricas informan sobre la utilización de E/S de datos en relación con el límite de almacenamiento en SSD local únicamente en la réplica de cómputo. Esto incluye la E/S contra la caché SSD local y 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 podría emitir.

La E/S de datos contra los servidores de páginas no se notifica en las vistas de uso de recursos ni en las métricas de Azure Monitor, pero se informa en sys.dm_io_virtual_file_stats(), como se ha descrito anteriormente.

Contenido relacionado

  • Last updated on