Exploración de escenarios de rendimiento

Completado

Para decidir cómo usar las herramientas y funcionalidades de rendimiento, es importante examinar el rendimiento de Azure SQL a través de escenarios.

Descripción de los escenarios de rendimiento comunes

Una técnica común para la solución de problemas de rendimiento de SQL Server consiste en examinar si un problema de rendimiento está En ejecución (uso elevado de CPU) o En espera (en espera de un recurso). En el siguiente diagrama se muestra un árbol de decisión para determinar si un problema de rendimiento de SQL Server está en ejecución o en espera, y cómo usar las herramientas de rendimiento para determinar la causa y la solución.

En primer lugar, examinemos el uso general de los recursos. En una implementación estándar de SQL Server, es posible usar herramientas como el Monitor de rendimiento en Windows o top en Linux. En el caso de Azure SQL, puede usar los métodos siguientes:

• Azure Portal, PowerShell o alertas

  Azure Monitor tiene métricas integradas para ver el uso de los recursos de Azure SQL. También se pueden configurar alertas para buscar condiciones de uso de recursos.

• sys.dm_db_resource_stats

  Para Azure SQL Database, puede examinar esta DMV para ver el uso de los recursos de CPU, memoria y E/S para la implementación de base de datos. En esta DMV se toma una instantánea de estos datos cada 15 segundos.

• sys.server_resource_stats

  Esta DMV se comporta como sys.dm_db_resource_stats, pero sirve para ver el uso de recursos de CPU, memoria y E/S de SQL Managed Instance. En esta DMV también se toma una instantánea cada 15 segundos.

• sys.dm_user_db_resource_governance

  En Azure SQL Database, esta DMW devuelve la configuración real y los valores de capacidad que usan los mecanismos de regulación de recursos en la base de datos o el grupo elástico actual.

• sys.dm_instance_resource_governance

  En Azure SQL Managed Instance, esta DMV devuelve información similar a sys.dm_user_db_resource_governance, pero para la instancia actual de SQL Managed Instance.

Correr

Si ha determinado que el problema es un uso elevado de la CPU, esto se denomina escenario en ejecución. Un escenario en ejecución puede implicar consultas que consumen recursos a través de la compilación o la ejecución. Use las siguientes herramientas para realizar un análisis más exhaustivo:

• Almacén de consultas

  Use los informes de recursos de mayor consumo en SSMS, las vistas de catálogo del Almacén de consultas o Información de rendimiento de consultas de Azure Portal (solo para Azure SQL Database) a fin de encontrar las consultas que más recursos de CPU consumen.

• sys.dm_exec_requests

  Use esta DMV en Azure SQL para obtener una instantánea del estado de las consultas activas. Busque consultas que tengan un estado de RUNNABLE y un tipo de espera de SOS_SCHEDULER_YIELD para ver si tiene suficiente capacidad de CPU.

• sys.dm_exec_query_stats

  Esta DMV se puede usar de forma muy parecida a Almacén de consultas para encontrar las consultas que consumen más recursos. Solo está disponible para los planes de consulta almacenados en caché, mientras que el Almacén de consultas proporciona un registro histórico persistente del rendimiento. Esta DMV también permite buscar el plan de consulta de una consulta en caché.

• sys.dm_exec_procedure_stats

  Esta DMV proporciona información similar a sys.dm_exec_query_stats, salvo que la información de rendimiento se puede ver en el nivel de procedimiento almacenado.

  Después de averiguar qué consulta o consultas consumen más recursos, puede que sea necesario examinar si disponemos de suficientes recursos de CPU para la carga de trabajo. Podemos depurar planes de consulta con herramientas como la generación de perfiles de consulta ligera, instrucciones SET, Almacén de consultas o el seguimiento de eventos extendidos.

En espera

Si el problema de rendimiento no parece ser un uso elevado de recursos de CPU, se podría deber a que implica la espera por un recurso. Los escenarios que implican la espera por recursos incluyen los siguientes:

• Esperas de E/S
• Esperas de bloqueo
• Tiempos de espera de bloqueo temporal
• Límites del grupo de búferes
• Concesiones de memoria
• Expulsión de la memoria caché de planes

Para realizar análisis en escenarios en espera, se suelen examinar las siguientes herramientas:

• sys.dm_os_wait_stats

  Use esta DMV para ver los tipos de espera principales de la base de datos o la instancia. Esto puede guiarle para elegir la acción siguiente en función de los tipos de espera principales.

• sys.dm_exec_requests

  Use esta DMV para buscar tipos de espera específicos para consultas activas y ver a qué recurso esperan. Puede tratarse de un escenario de bloqueo estándar que espera a los bloqueos de otros usuarios.

• sys.dm_os_waiting_tasks

  Puede usar esta DMV para buscar tipos de espera para una tarea determinada para una consulta específica que se está ejecutando actualmente, quizás para ver por qué tarda más de lo normal. sys.dm_os_waiting_tasks contiene las estadísticas de espera en directo que sys.dm_os_wait_stats agrega a lo largo del tiempo.

• Almacén de consultas

  Almacén de consultas proporciona informes y vistas de catálogo que muestran una agregación de las esperas principales de la ejecución del plan de consulta. Es importante saber que una espera de CPU es equivalente a un problema en ejecución.

Escenarios específicos de Azure SQL

Existen algunos escenarios de rendimiento, tanto en ejecución como en espera, que son específicos de Azure SQL, como la gobernanza de registros, los límites de trabajo, las esperas detectadas en los niveles de servicio Crítico para la empresa y las esperas específicas de una implementación de hiperescala.

Gobernanza de registros

Azure SQL puede usar la gobernanza de frecuencia de registros para aplicar límites de recursos al uso del registro de transacciones. Esto puede ser necesario para garantizar los límites de recursos y cumplir el acuerdo de nivel de servicio prometido. La gobernanza de registros puede aparecer en los tipos de espera siguientes:

• LOG_RATE_GOVERNOR: espera a Azure SQL Database
• POOL_LOG_RATE_GOVERNOR: espera a grupos elásticos
• INSTANCE_LOG_GOVERNOR: espera a Azure SQL Managed Instance
• HADR_THROTTLE_LOG_RATE*: espera a la latencia crítica para la empresa y de replicación geográfica

Límites de trabajo

SQL Server usa un grupo de trabajo de subprocesos pero tiene límites sobre el número máximo de trabajos. Las aplicaciones con un gran número de usuarios simultáneos podrían abordar los límites de trabajo aplicados para Azure SQL Database y Azure SQL Managed Instance:

• Azure SQL Database tiene límites basados en el nivel de servicio y el tamaño. Si supera este límite, una consulta nueva recibe un error.
• Actualmente, SQL Managed Instance usa max worker threads para que los trabajos que superen este límite puedan ver las esperas THREADPOOL.

Esperas de alta disponibilidad y recuperación ante desastres críticas para la empresa

Si se usa un nivel de servicio Crítico para la empresa, es posible que aparezcan los siguientes tipos de espera de forma inesperada:

• HADR_SYNC_COMMIT
• HADR_DATABASE_FLOW_CONTROL
• HADR_THROTTLE_LOG_RATE_SEND_RECV

Si bien estas esperas no ralentizarán la aplicación, posiblemente no esté previsto que aparezcan. Por lo general, son específicas del uso de un grupo de disponibilidad de Always On. Los niveles Crítico para la empresa usan la tecnología de los grupos de disponibilidad para implementar el SLA y las características de disponibilidad de un nivel de servicio Crítico para la empresa, por lo que estos tipos de espera deben estar previstos. Los tiempos de espera prolongados pueden ser indicio de un cuello de botella como, por ejemplo, de latencia de E/S o de réplica.

Hiperescala

La arquitectura Hiperescala puede generar algunos tipos de espera únicos con el prefijo RBIO (un posible indicador de la gobernanza de registros). Además, las DMV, las vistas de catálogo y los eventos extendidos se mejoran para mostrar métricas para las lecturas del servidor de páginas.

En el ejercicio siguiente, aprenderá a supervisar y solucionar un problema de rendimiento de Azure SQL usando las herramientas y conocimientos adquiridos en esta unidad.