Ejercicio: Escala del rendimiento de la carga de trabajo

  • 10 minutos

En este ejercicio, recuperará el problema que ha encontrado en el primero y mejorará el rendimiento mediante el escalado de más CPU para Azure SQL Database. Usará la base de datos que ha implementado en el ejercicio anterior.

Puede encontrar todos los scripts de este ejercicio en la carpeta 04-Performance\monitor_and_scale en el repositorio de GitHub que ha clonado o el archivo ZIP que ha descargado.

Escalado vertical del rendimiento de Azure SQL

Para escalar el rendimiento y solucionar un problema que parece ser de capacidad de CPU, debe decidir qué opciones tiene y, después, continuar con el escalado de las CPU usando las interfaces proporcionadas para Azure SQL.

  1. Decida cómo escalar el rendimiento. Como la carga de trabajo está enlazada a la CPU, una manera de mejorar el rendimiento consiste en aumentar la capacidad o la velocidad de la CPU. Un usuario de SQL Server tendría que cambiar a otro equipo o volver a configurar una máquina virtual para obtener más capacidad de CPU. En algunos casos, hasta un administrador de SQL Server podría no tener permiso para realizar estos cambios de escalado. El proceso puede tardar tiempo e, incluso, requerir una migración de la base de datos.

    En Azure, se puede usar ALTER DATABASE, la CLI de Azure o Azure Portal para aumentar la capacidad de CPU sin que el usuario tenga que migrar la base de datos.

  2. Con Azure Portal, se pueden ver opciones de escalado para obtener más recursos de CPU. En el panel Información general de la base de datos, seleccione la implementación actual del Plan de tarifa. En Plan de tarifa puede cambiar el nivel de servicio y el número de núcleos virtuales.

    Screenshot of changing service tier in the Azure portal.

  3. Aquí puede ver opciones para cambiar o escalar los recursos de proceso. En De uso general se pueden escalar fácilmente a 8 núcleos virtuales, por ejemplo.

    Screenshot of compute options in the Azure portal.

    También puede usar un método diferente para escalar la carga de trabajo.

  4. En este ejercicio, para poder ver las diferencias adecuadas en los informes, primero tendrá que vaciar el almacén de consultas. En SQL Server Management Studio (SSMS), seleccione la base de datos AdventureWorks y use el menú Archivo>Abrir>Archivo. En SSMS, abra el script flushhquerystore.sql en el contexto de la base de datos AdventureWorks. La ventana del editor de consultas debería tener un aspecto similar al siguiente:

    EXEC sp_query_store_flush_db;

    Seleccione Ejecutar para ejecutar este lote de T-SQL.

    Nota:

    La ejecución de la consulta anterior vacía la parte en memoria de los datos del Almacén de consultas en el disco.

  5. Abra el script get_service_objective.sql en SSMS. La ventana del editor de consultas debería tener un aspecto similar al siguiente:

    SELECT database_name,slo_name,cpu_limit,max_db_memory, max_db_max_size_in_mb, primary_max_log_rate,primary_group_max_io, volume_local_iops,volume_pfs_iops
FROM sys.dm_user_db_resource_governance;
GO
SELECT DATABASEPROPERTYEX('AdventureWorks', 'ServiceObjective');
GO

    Este método permite determinar el nivel de servicio por medio de T-SQL. El nivel de tarifa o de servicio también se conoce como objetivo de servicio. Seleccione Ejecutar para ejecutar los lotes de T-SQL.

    En la implementación de Azure SQL Database actual, los resultados deberían ser similares a los de la imagen siguiente:

    Screenshot of service objective results.

    Observe que el término slo_name también se usa para el objetivo de servicio. slo significa objetivo de nivel de servicio.

    Los distintos valores slo_name no están documentados, pero en el valor de cadena se puede ver que esta base de datos usa un nivel de servicio De uso general con dos núcleos virtuales:

    Nota:

    SQLDB_OP_... es la cadena que se usa para Crítico para la empresa.

    Cuando consulte la documentación de ALTER DATABASE, observe que puede seleccionar la implementación de SQL Server de destino para obtener las opciones de sintaxis correctas. Seleccione la base de datos única o grupo elástico de SQL Database para ver las opciones de Azure SQL Database. Para que coincida con la escala de proceso que ha encontrado en el portal, necesita el objetivo de servicio 'GP_Gen5_8'.

  6. Modifique el objetivo de servicio para que la base de datos escale más CPU. Abra el script modify_service_objective.sql en SSMS y ejecute el lote de T-SQL. La ventana del editor de consultas debería tener un aspecto similar al siguiente:

    ALTER DATABASE AdventureWorks MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');

    Esta instrucción devuelve un resultado inmediato, pero el escalado de los recursos de proceso se produce en segundo plano. Una escala tan pequeña debe tardar menos de un minuto y durante un breve período de tiempo la base de datos estará sin conexión para que el cambio surta efecto. El progreso de esta actividad de escalado se puede supervisar en Azure Portal.

    Screenshot of update in the Azure portal.

  7. En Explorador de objetos, en la carpeta Bases de datos del sistema, haga clic con el botón derecho en la base de datos maestra y seleccione Nueva consulta. Ejecute esta consulta en la ventana del editor de consultas de SSMS:

    SELECT * FROM sys.dm_operation_status;

    Es otra manera de supervisar el progreso de un cambio de objetivo de servicio para Azure SQL Database. En esta vista de administración dinámica (DMV) se muestra un historial de cambios en la base de datos con ALTER DATABASE para el objetivo de servicio, así como el progreso activo del cambio.

    Este es un ejemplo de la salida de esta DMV en formato de tabla, después de ejecutar la instrucción ALTER DATABASE anterior:

    Elemento Value
    session_activity_id 97F9474C-0334-4FC5-BFD5-337CDD1F9A21
    resource_type 0
    resource_type_desc Base de datos
    major_resource_id AdventureWorks
    minor_resource_id
    operation ALTER DATABASE
    state 1
    state_desc IN_PROGRESS
    percent_complete 0
    error_code 0
    error_desc
    error_severity 0
    error_state 0
    start_time [fecha y hora]
    last_modify_time [fecha y hora]

    Durante un cambio en el objetivo de servicio, se permiten consultas en la base de datos hasta que se implemente el cambio final. Una aplicación no se podrá conectar durante un breve período de tiempo. En Azure SQL Managed Instance, un cambio de nivel permite las consultas y las conexiones, pero impide que puedan realizarse operaciones de base de datos, como crear una, por ejemplo. En estos casos, recibirá un mensaje de error que indica que no se pudo completar la operación porque hay un cambio de nivel de servicio en curso para la instancia administrada en cuestión, y que hay que esperar a que la operación que está en curso finalice.

  8. Cuando termine, use las consultas anteriores de get_service_objective.sql en SSMS para confirmar que el nuevo objetivo de servicio o el nivel de servicio de 8 núcleos virtuales ha entrado en vigor.

Ejecución de la carga de trabajo después de escalar verticalmente

Ahora que la base de datos tiene más capacidad de CPU, se ejecutará la carga de trabajo del ejercicio anterior para observar si hay una mejora del rendimiento.

  1. Una vez completado el escalado, fíjese en si la duración de la carga de trabajo es más rápida y si la espera de recursos de CPU ha disminuido. Vuelva a ejecutar la carga de trabajo con el comando sqlworkload.cmd que ejecutamos en el ejercicio anterior.

  2. Con SSMS, ejecute la misma consulta del primer ejercicio de este módulo para observar los resultados del script dmdbresourcestats.sql:

    SELECT * FROM sys.dm_db_resource_stats;

    Debería ver que el uso medio de recursos de la CPU se ha reducido con respecto a casi el 100 por cien que obtuvimos en el ejercicio anterior. Normalmente, sys.dm_db_resource_stats muestra una hora de actividad. Cambiar el tamaño de la base de datos hace que sys.dm_db_resource_stats se restablezca.

  3. Con SSMS, ejecute la misma consulta del primer ejercicio de este módulo para observar los resultados del script dmexecrequests.sql.

    SELECT er.session_id, er.status, er.command, er.wait_type, er.last_wait_type, er.wait_resource, er.wait_time
FROM sys.dm_exec_requests er
INNER JOIN sys.dm_exec_sessions es
ON er.session_id = es.session_id
AND es.is_user_process = 1;

    Verá que hay más consultas con el estado "RUNNING". Esto significa que los trabajos tienen más capacidad de CPU para ejecutarse.

  4. Observe la nueva duración de la carga de trabajo. La duración de la carga de trabajo de sqlworkload.cmd debería ser mucho menor, aproximadamente entre 25-30 segundos.

Examen de los informes del Almacén de consultas

Ahora se verán los mismos informes del Almacén de consultas que en el ejercicio anterior.

  1. Con las mismas técnicas que en el primer ejercicio de este módulo, examine el informe Consultas que más recursos consumen en SSMS:

    Screenshot of top query results running faster.

    Ahora aparecerán dos consultas (query_id). Se trata de la misma consulta, pero mostrada como valores query_id diferentes en el Almacén de consultas, porque la operación de escala ha necesitado un reinicio para volver a compilar la consulta. En el informe, puede ver que la duración total y la media son significativamente menores.

  2. Observe también el informe Estadísticas de espera de consulta y seleccione la barra Esperas de CPU. Se ve que el tiempo medio de espera de la consulta es menor y un porcentaje inferior de la duración total. Esto es buena señal de que la CPU no es el mismo cuello de botella de recursos que cuando la base de datos tenía menos núcleos virtuales:

    Screenshot of top wait statistics results running faster.

  3. Puede cerrar todos los informes y las ventanas del editor de consultas. Deje SSMS conectado, ya que lo necesitaremos en el siguiente ejercicio.

Observación de los cambios en las métricas de Azure

  1. Vaya a la base de datos AdventureWorks de Azure Portal y busque en la pestaña Supervisión del panel Introducción de nuevo para Uso de procesos:

    Screenshot of compute comparison in the Azure portal.

    Fíjese en que la duración es menor cuando el uso de la CPU es elevado, lo que significa una reducción general de los recursos de CPU necesarios para ejecutar la carga de trabajo.

  2. Este gráfico puede ser algo confuso. En el menú Supervisión, use Métricas, después establezca la Métrica en Límite de CPU. El gráfico de comparación de CPU tiene un aspecto parecido al siguiente:

    Screenshot of query comparison in the Azure portal.

Sugerencia

Si continúa aumentando los núcleos virtuales de esta base de datos, puede mejorar el rendimiento hasta un umbral en el que todas las consultas tengan una gran cantidad de recursos de CPU. Esto no significa que el número de núcleos virtuales deba coincidir con el número de usuarios simultáneos de la carga de trabajo. Además, puede cambiar el plan de tarifa para usar el nivel de proceso Sin servidor, en lugar de Aprovisionado. lo que ayudará a lograr un enfoque más "de escalado automático" en una carga de trabajo. Por ejemplo, si eligió un valor mínimo de núcleo virtual de 2 para esta carga de trabajo y el valor máximo de núcleo virtual de 8, esta carga de trabajo se escalaría inmediatamente a 8 núcleos virtuales.

En el siguiente ejercicio, nos centraremos en un problema de rendimiento y lo resolveremos usando procedimientos recomendados de rendimiento de la aplicación.