Administración de recursos en grupos elásticos densos

  • Artículo

Se aplica a:Azure SQL Database

Los grupos elásticos de Azure SQL Database son una solución rentable para administrar muchas bases de datos con un uso de recursos variable. Todas las bases de datos de un grupo elástico comparten la misma asignación de recursos, como CPU, memoria, subprocesos de trabajo, espacio de almacenamiento o tempdb, suponiendo que solo un subconjunto de bases de datos del grupo usa recursos de proceso en un momento dado. Este supuesto permite que los grupos elásticos sean rentables. En lugar de pagar por todos los recursos que podría necesitar cada base de datos individual, los clientes pagan por un conjunto de recursos mucho más pequeño, que comparten todas las bases de datos del grupo.

Regulación de recursos

El uso compartido de recursos requiere que el sistema controle cuidadosamente el uso de recursos para minimizar el efecto de "vecino ruidoso", donde una base de datos con un consumo elevado de recursos afecta a otras bases de datos del mismo grupo elástico. Azure SQL Database logra estos objetivos mediante la implementación de la gobernanza de recursos. Al mismo tiempo, el sistema debe proporcionar recursos suficientes para características como alta disponibilidad y recuperación ante desastres (HADR), copia de seguridad y restauración, supervisión, Almacén de consultas y ajuste automático, entre otros, para que funcione de manera confiable.

El objetivo de diseño principal de los grupos elásticos es la rentabilidad. Por esta razón, el sistema permite a los clientes de forma intencionada crear grupos densos, es decir, grupos con un número de bases de datos que se aproximen o alcancen el máximo permitido, pero con una asignación moderada de recursos de proceso. Por la misma razón, el sistema no reserva todos los recursos potencialmente necesarios para sus procesos internos, sino que permite que se compartan entre estos procesos y las cargas de trabajo de usuario.

Este enfoque permite que los clientes usen grupos elásticos densos para conseguir un rendimiento adecuado y mayores ahorros en los costos. Sin embargo, si la carga de trabajo en muchas bases de datos de un grupo denso es suficientemente intensa, la contención de recursos puede ser considerable. La contención de recursos reduce el rendimiento de la carga de trabajo del usuario y puede afectar de forma negativa a los procesos internos.

Importante

En los grupos densos con muchas bases de datos activas, puede no ser factible aumentar el número de bases de datos del grupo hasta los máximos documentados para los grupos elásticos por DTU y núcleo virtual.

El número de bases de datos que se puede colocar en los grupos densos sin causar problemas de contención de recursos y rendimiento depende del número de bases de datos activas simultáneamente y de los recursos consumidos por las cargas de trabajo de usuario en cada base de datos. Este número puede cambiar con el tiempo a medida que cambian las cargas de trabajo del usuario.

Además, si el número mínimo de núcleos virtuales por base de datos o el número mínimo de DTU por configuración de base de datos se establece en un valor mayor que 0, el número máximo de bases de datos del grupo se limitará implícitamente. Para obtener más información, vea Propiedades de base de datos para bases de datos de núcleos virtuales agrupadas y Propiedades de base de datos para bases de datos de DTU agrupadas.

Cuando se produce la contención de recursos en un grupo empaquetado de forma densa, los clientes pueden elegir una o varias de las siguientes acciones para mitigarla:

  • Ajuste la carga de trabajo de consulta para reducir el consumo de recursos o divida el consumo de recursos entre varias bases de datos a lo largo del tiempo.
  • Reducir la densidad del grupo trasladando algunas bases de datos a otro grupo o convirtiéndolas en bases de datos independientes.
  • Escalar verticalmente el grupo para obtener más recursos.

Para obtener sugerencias sobre cómo implementar las dos últimas acciones, consulte Recomendaciones operativas más adelante en este artículo. La reducción de la contención de recursos beneficia tanto a las cargas de trabajo de los usuarios como a los proceso internos, y permite que el sistema mantenga de manera confiable el nivel de servicio esperado.

Supervisión del consumo de recursos

Para evitar la degradación del rendimiento debido a la contención de recursos, los clientes que usen grupos elásticos densos deben supervisar proactivamente el consumo de recursos y realizar acciones oportunas si el aumento de esta empieza a afectar a las cargas de trabajo. La supervisión continua es importante porque el uso de recursos en un grupo cambia con el tiempo debido a los cambios en la carga de trabajo del usuario, los cambios en los volúmenes de datos y la distribución, los cambios en la densidad del grupo y los cambios en servicio Azure SQL Database.

Azure SQL Database proporciona varias métricas que son de interés para este tipo de supervisión. Superar el valor medio recomendado de cada métrica indica la contención de recursos en el grupo y se debe solucionar mediante una de las acciones mencionadas anteriormente.

Para enviar una alerta cuando el uso de recursos del grupo (CPU, E/S de datos, E/S de registro, roles de trabajo, etc.) supera un umbral, considere la posibilidad de crear alertas a través de Azure Portal o el cmdlet Add-AzMetricAlertRulev2 de PowerShell. Al supervisar grupos elásticos, considere también la posibilidad de crear alertas para bases de datos individuales del grupo si es necesario en su escenario. Para obtener un escenario de ejemplo para la supervisión de grupos elásticos, consulte Supervisión y administración del rendimiento de Azure SQL Database en una aplicación SaaS multiinquilino.

Nombre de métrica Descripción Valor medio recomendado
avg_instance_cpu_percent Uso de CPU del proceso de SQL asociado a un grupo elástico, medido por el sistema operativo subyacente. Disponible en la vista sys.dm_db_resource_stats de cada base de datos y en la vista sys.elastic_pool_resource_stats de la base de datos master. Esta métrica también se emite para Azure Monitor, donde se denominasql_instance_cpu_percent, y se puede ver en Azure Portal. Este valor es el mismo para todas las bases de datos del mismo grupo elástico. Por debajo del 70 %. Pueden ser aceptables picos breves ocasionales hasta el 90 %.
max_worker_percent Utilización de subprocesos de trabajo. Se proporciona para cada base de datos del grupo, así como para el propio grupo. Hay diferentes límites en el número de subprocesos de trabajo en el nivel de base de datos y en el nivel de grupo; por lo tanto, se recomienda supervisar esta métrica en ambos niveles. Disponible en la vista sys.dm_db_resource_stats de cada base de datos y en la vista sys.elastic_pool_resource_stats de la base de datos master. Esta métrica también se emite para Azure Monitor, donde se denominaworkers_percent, y se puede ver en Azure Portal. Por debajo del 80 %. Los picos hasta el 100 % provocarán errores en los intentos de conexión y las consultas.
avg_data_io_percent Uso de IOPS para la E/S física de lectura y escritura. Se proporciona para cada base de datos del grupo, así como para el propio grupo. Hay distintos límites en el número de IOPS en el nivel de base de datos y en el nivel de grupo; por lo tanto, se recomienda supervisar esta métrica en ambos niveles. Disponible en la vista sys.dm_db_resource_stats de cada base de datos y en la vista sys.elastic_pool_resource_stats de la base de datos master. Esta métrica también se emite para Azure Monitor, donde se denominaphysical_data_read_percent, y se puede ver en Azure Portal. Por debajo del 80 %. Pueden ser aceptables picos breves ocasionales hasta el 100 %.
avg_log_write_percent Usos del rendimiento para la E/S de escritura del registro de transacciones. Se proporciona para cada base de datos del grupo, así como para el propio grupo. Hay diferentes límites en el rendimiento de registros en el nivel de base de datos y en el nivel de grupo; por lo tanto, se recomienda supervisar esta métrica en ambos niveles. Disponible en la vista sys.dm_db_resource_stats de cada base de datos y en la vista sys.elastic_pool_resource_stats de la base de datos master. Esta métrica también se emite para Azure Monitor, donde se denominalog_write_percent, y se puede ver en Azure Portal. Cuando esta métrica esté cerca del 100 %, todas las modificaciones de base de datos (instrucciones INSERT, UPDATE, DELETE, MERGE, SELECT … INTO, BULK INSERT, etc.) serán más lentas. Por debajo del 90 %. Pueden ser aceptables picos breves ocasionales hasta el 100 %.
oom_per_second La tasa de errores de memoria insuficiente (OOM) en un grupo elástico, que es un indicador de la presión de memoria. Disponible en la vista sys.dm_resource_governor_resource_pools_history_ex. Consulte la sección Ejemplos para ver una consulta de ejemplo para calcular esta métrica. Para más información, consulte los límites de recursos para grupos elásticos mediante DTU o grupos elásticos mediante núcleos virtuales y Solución de problemas de memoria con Azure SQL Database. Si encuentra errores de memoria insuficiente, revise sys.dm_os_out_of_memory_events. 0
avg_storage_percent Espacio de almacenamiento total usado por los datos de todas las bases de datos de un grupo elástico. No incluye el espacio vacío en los archivos de base de datos. Disponible en la vista sys.elastic_pool_resource_stats de la base de datos master. Esta métrica también se emite para Azure Monitor, donde se denominastorage_percent, y se puede ver en Azure Portal. Por debajo del 80 %. Puede aproximarse al 100 % en grupos sin crecimiento de datos.
avg_allocated_storage_percent Espacio de almacenamiento total que usan los archivos de base de datos en el almacenamiento en todas las bases de datos de un grupo elástico. Incluye el espacio vacío en los archivos de base de datos. Disponible en la vista sys.elastic_pool_resource_stats de la base de datos master. Esta métrica también se emite para Azure Monitor, donde se denominaallocated_data_storage_percent, y se puede ver en Azure Portal. Por debajo del 90 %. Puede aproximarse al 100 % en grupos sin crecimiento de datos.
tempdb_log_used_percent Utilización del espacio de registro de transacciones en la base de datos de tempdb. Aunque los objetos temporales creados en una base de datos no están visibles en otras bases de datos del mismo grupo elástico, tempdb es un recurso compartido por todas las bases de datos del mismo grupo. Una transacción de larga duración o huérfana en tempdb iniciada desde una base de datos del grupo puede consumir una gran parte del registro de transacciones y producir errores en las consultas de otras bases de datos del mismo grupo. Deriva de las vistas sys.dm_db_log_space_usage y sys.database_files. Esta métrica también se emite para Azure Monitor, y se puede ver en Azure Portal. Consulte la sección de Ejemplos para ver una consulta de ejemplo que devuelve el valor actual de esta métrica. Por debajo del 50 % Son aceptables picos ocasionales de hasta el 80 %.

Además de estas métricas, Azure SQL Database proporciona una vista que devuelve los límites reales de la regulación de recursos, así como vistas adicionales que devuelven estadísticas de uso de recursos en el nivel de grupo de recursos y en el nivel de grupo de cargas de trabajo.

Nombre de la vista Descripción
sys.dm_user_db_resource_governance Devuelve la configuración y los valores de capacidad reales que usan los mecanismos de regulación de recursos en la base de datos o el grupo elástico actuales.
sys.dm_resource_governor_resource_pools Devuelve información sobre el estado actual del grupo de recursos, la configuración actual de los grupos de recursos y las estadísticas acumuladas del grupo de recursos.
sys.dm_resource_governor_workload_groups Devuelve las estadísticas acumuladas del grupo de cargas de trabajo y su configuración actual. Esta vista puede combinarse con sys.dm_resource_governor_resource_pools en la columna pool_id para obtener información del grupo de recursos.
sys.dm_resource_governor_resource_pools_history_ex Devuelve estadísticas de uso del grupo de recursos para el historial reciente, en función del número de instantáneas disponibles. Cada fila representa un intervalo de tiempo. La duración del intervalo se proporciona en la columna duration_ms. Las columnas delta_ devuelven el cambio en cada estadística durante el intervalo.
sys.dm_resource_governor_workload_groups_history_ex Devuelve estadísticas de uso del grupo de cargas de trabajo para el historial reciente, en función del número de instantáneas disponibles. Cada fila representa un intervalo de tiempo. La duración del intervalo se proporciona en la columna duration_ms. Las columnas delta_ devuelven el cambio en cada estadística durante el intervalo.

Sugerencia

Para consultar estas y otras vistas de administración dinámica mediante una entidad de seguridad que no sea el administrador del servidor, agregue esta entidad de seguridad al rol de servidor##MS_ServerStateReader##.

Estas vistas se pueden usar para supervisar el uso de recursos y solucionar problemas de contención de recursos casi en tiempo real. La carga de trabajo de usuario de las réplicas primarias y secundarias legibles, incluidas las réplicas geográficas, se clasifica en el grupo de recursos SloSharedPool1 y en el grupo de cargas de trabajo UserPrimaryGroup.DBId[N], donde N representa el valor del identificador de base de datos.

Además de supervisar el uso de recursos actual, los clientes que usan grupos densos pueden mantener datos de uso de recursos históricos en un almacén de datos independiente. Estos datos se pueden usar en análisis predictivos para administrar de forma proactiva el uso de recursos en función de las tendencias históricas y estacionales.

Recomendaciones operativas

Deje suficiente espacio para los recursos. En caso de producirse contención de recursos y degradación del rendimiento, la mitigación puede implicar sacar algunas bases de datos fuera del grupo elástico afectado o escalar verticalmente el grupo, como se indicó anteriormente. Sin embargo, para realizar estas acciones se requieren recursos de proceso adicionales. En concreto, en el caso de los grupos Premium y Crítico para la empresa, estas acciones requieren la transferencia de todos los datos de las bases de datos que se van a migrar o de todas las bases de datos del grupo elástico si el grupo se escala verticalmente. La transferencia de datos es una operación de larga duración que consume muchos recursos. Si el grupo ya tiene una elevada presión de recursos, la operación de mitigación en sí reducirá el rendimiento aún más. En casos extremos, puede que no sea posible resolver la contención de recursos mediante la migración de la base de datos o el escalado horizontal del grupo, ya que los recursos necesarios no están disponibles. En este caso, puede que la única solución pase por reducir temporalmente la carga de trabajo de consultas en el grupo elástico afectado.

Los clientes que usen grupos densos deben supervisar de cerca las tendencias de utilización de recursos descritas anteriormente y llevar a cabo acciones de mitigación mientras las métricas permanezcan dentro de los intervalos recomendados y todavía haya suficientes recursos en el grupo elástico.

La utilización de recursos depende de varios factores que cambian con el tiempo en cada base de datos y cada grupo elástico. Conseguir una relación óptima de precio/rendimiento en grupos densos requiere una supervisión y un reequilibrio continuos, que suponen migrar las bases de datos de los grupos más utilizados a los menos utilizados y crear grupos según sea necesario para dar cabida a una mayor carga de trabajo.

Nota

En el caso de los grupos elásticos de DTU, la métrica eDTU en el nivel de grupo no es una operación MAX o SUM del uso individual de la base de datos. Se deriva de la utilización de varias métricas del nivel de grupo. Los límites de recursos en el nivel del grupo pueden ser superiores a los límites individuales en el nivel de base de datos, por lo que es posible que una base de datos individual pueda alcanzar un límite de recursos específico (CPU, E/S de datos, E/S de registro, etc.), incluso cuando los informes de eDTU del grupo indiquen que no se ha alcanzado ningún límite.

No mueva las bases de datos "activas". Si la contención de recursos en el nivel de grupo se debe principalmente a un número pequeño de bases de datos muy utilizadas, puede ser tentador migrar estas bases de datos a un grupo menos utilizado o convertirlas en bases de datos independientes. Sin embargo, no es el enfoque recomendado mientras una base de datos presente una utilización muy alta, ya que la operación de migración disminuirá aún más el rendimiento, tanto para la base de datos que se migra como para todo el grupo. En su lugar, espere a que la alta utilización disminuya o migre las bases de datos menos utilizadas en lugar de aligerar la presión de los recursos en el nivel de grupo. Sin embargo, mover las bases de datos con una utilización muy baja no proporciona ninguna ventaja en este caso, ya que no reduce sustancialmente la utilización de recursos en el nivel de grupo.

Cree bases de datos en un grupo de "cuarentena". En escenarios donde se crean con frecuencia bases de datos, como las aplicaciones que usan el modelo de inquilino por base de datos, existe el riesgo de que una nueva base de datos colocada en un grupo elástico existente consuma inesperadamente una cantidad considerable de recursos y afecte a otras bases de datos y procesos internos del grupo. Para mitigar este riesgo, cree un grupo de "cuarentena" aparte con asignación amplia de recursos. Use este grupo con bases de datos nuevas en las que se desconozcan los patrones de consumo de recursos. Una vez que una base de datos se ha mantenido en este grupo durante un ciclo comercial, como una semana o un mes, y se conoce su consumo de recursos, se puede migrar a un grupo con capacidad suficiente como para dar cabida a este uso adicional de recursos.

Supervise el espacio usado y asignado. Cuando el espacio de grupo asignado (tamaño total de todos los archivos de base de datos en almacenamiento para todas las bases de datos de un grupo) alcanza el tamaño máximo del grupo, pueden producirse errores de espacio insuficiente. Si el espacio asignado tiende a ser alto y está en camino de alcanzar el tamaño máximo del grupo, las opciones de mitigación incluyen:

  • Sacar algunas bases de datos del grupo para reducir el espacio total asignado
  • Reducir archivos de base de datos para limitar el espacio asignado vacío en los archivos
  • Escalar verticalmente el grupo a un objetivo de servicio con un tamaño de grupo máximo mayor

Si el espacio de grupo utilizado (tamaño total de datos en todas las bases de datos de un grupo, sin incluir el espacio vacío en los archivos) tiende a ser alto y está en camino de alcanzar el tamaño máximo del grupo, las opciones de mitigación incluyen:

  • Sacar algunas bases de datos del grupo para reducir el espacio total utilizado
  • Sacar (archivar) datos de la base de datos o eliminar los datos que ya no sean necesarios
  • Implementar la compresión de datos
  • Escalar verticalmente el grupo a un objetivo de servicio con un tamaño de grupo máximo mayor

Evite servidores demasiado densos. Azure SQL Database admite hasta 5000 bases de datos por servidor. Los clientes que usan grupos elásticos con miles de bases de datos podrían colocar varios grupos elásticos en un solo servidor, con el número total de bases de datos hasta el límite admitido. Sin embargo, los servidores con muchos miles de bases de datos presentan complicaciones operativas. Las operaciones que requieren la enumeración de todas las bases de datos de un servidor, por ejemplo, la visualización de las bases de datos en el portal, serán más lentas. Los errores operativos, como la modificación incorrecta de los inicios de sesión de nivel de servidor o las reglas de firewall, afectarán a un mayor número de bases de datos. La eliminación accidental del servidor requerirá la asistencia del servicio de soporte técnico de Microsoft para recuperar las bases de datos del servidor eliminado y provocará una interrupción prolongada en todas las bases de datos afectadas.

Limite el número de bases de datos por servidor a un número menor que el máximo admitido. En muchos escenarios, el uso de hasta 1000 o 2000 bases de datos por servidor se considera óptimo. Para reducir la probabilidad de eliminación accidental del servidor, coloque un bloqueo de eliminación en el servidor o en su grupo de recursos.

Ejemplos

Visualización de la configuración de capacidad de la base de datos individual

Use la vista de administración dinámica sys.dm_user_db_resource_governance para ver la configuración real y la configuración de capacidad que usa la gobernanza de recursos en la base de datos o el grupo elástico actual. Para más información, consulte sys.dm_user_db_resource_governance.

Ejecute esta consulta en cualquier base de datos de un grupo elástico. Todas las bases de datos del grupo tienen la misma configuración de gobernanza de recursos.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

Supervisión del consumo general de recursos del grupo elástico

Use la vista de catálogo del sistema sys.elastic_pool_resource_stats para supervisar el consumo de recursos de todo el grupo. Para más información, consulte sys.elastic_pool_resource_stats.

Esta consulta de ejemplo para ver los últimos 10 minutos debe ejecutarse en la base de datos master del servidor lógico de Azure SQL que contiene el grupo elástico deseado.

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

Supervisión del consumo de recursos de una base de datos individual

Use la vista de administración dinámica sys.dm_db_resource_stats para supervisar el consumo de recursos de bases de datos individuales. Para más información, consulte sys.dm_db_resource_stats. Hay una fila para cada 15 segundos, incluso si no hay ninguna actividad. Los datos históricos se mantienen aproximadamente durante una hora.

Esta consulta de ejemplo para ver los últimos 10 minutos de datos debe ejecutarse en la base de datos de su elección.

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

Para un tiempo de retención más largo con una frecuencia menor, considere la siguiente consulta en sys.resource_stats y ejecute en la base de datos master del servidor lógico de Azure SQL. Para más información, consulte sys.resource_stats (Azure SQL Database). Existe una fila cada cinco minutos y los datos históricos se mantienen durante dos semanas.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

Supervisión del uso de memoria

Esta consulta calcula la métrica oom_per_second de cada grupo de recursos para el historial reciente, en función del número de instantáneas disponibles. Esta consulta de ejemplo ayuda a identificar el número medio reciente de asignaciones de memoria con errores en el grupo. Se puede ejecutar en cualquier base de datos de un grupo elástico.

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

Supervisión de la utilización del espacio de registros tempdb

Esta consulta devuelve el valor actual de la métrica tempdb_log_used_percent, que muestra la utilización relativa del registro de transacciones tempdb con respecto al tamaño máximo permitido. Se puede ejecutar en cualquier base de datos de un grupo elástico.

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

Pasos siguientes