¿Por qué mi base de datos Azure SQL (SQL Server) se sobrecarga con datos IO por períodos a la vez? [cerrado]

Estoy ejecutando una base de datos SQL de Azure en la edición S2 (50 DTU). El uso normal del servidor generalmente se cuelga alrededor del 10% de DTU. Sin embargo, este servidor entra regularmente en un estado donde enviará el uso de DTU de la base de datos al 85-90% durante horas. Luego, de repente, vuelve al uso normal del 10%.

Las consultas contra el servidor desde la aplicación todavía parecen estar funcionando rápidamente durante este estado sobrecargado.

Puedo escalar el servidor desde S2 => cualquier cosa (S3, por ejemplo) => S2 y parece borrar cualquier estado en el que esté colgado. Pero unas horas más tarde volverá a repetir el mismo ciclo de estado sobrecargado. Otra cosa extraña que he notado es que si ejecuto este servidor en un plan S3 (100 DTU) 24/7, no he observado este comportamiento. Solo parece ocurrir cuando reduje la escala de la base de datos a un plan S2 (50 DTU). En el plan S3 siempre estoy sentado con un uso de DTU del 5-10%. Obviamente subutilizado.

Revisé los informes de consultas SQL de Azure en busca de consultas falsas, pero realmente no veo nada inusual y muestra mis consultas utilizando recursos como era de esperar.

Sin embargo, como podemos ver aquí, el uso proviene de Data IO. Si cambio el informe de rendimiento aquí para mostrar las principales consultas de Data IO de MAX, vemos esto:

Mirar estos deseos de larga duración parece apuntar a actualizaciones de estadísticas. Realmente no hay nada que se ejecute desde mi aplicación. Por ejemplo, la consulta 16302 allí muestra:

SELECT StatMan([SC0], [SC1], [SC2], [SB0000]) FROM (SELECT TOP 100 PERCENT [SC0], [SC1], [SC2], step_direction([SC0]) over (order by NULL) AS [SB0000]  FROM (SELECT [UserId] AS [SC0], [OrganizationId] AS [SC1], [Id] AS [SC2] FROM [dbo].[Cipher] TABLESAMPLE SYSTEM (1.250395e+000 PERCENT) WITH (READUNCOMMITTED) ) AS _MS_UPDSTATS_TBL_HELPER ORDER BY [SC0], [SC1], [SC2], [SB0000] ) AS _MS_UPDSTATS_TBL  OPTION (MAXDOP 16)

Pero, de nuevo, el informe también muestra que estas consultas solo utilizan un pequeño porcentaje del uso de Data IO en el servidor (<4%). También ejecuto actualizaciones de estadísticas (y reconstrucciones de índice) en toda la base de datos semanalmente como parte de su mantenimiento regular.

Aquí hay otro informe que muestra las consultas de IO de datos MAX para un intervalo de tiempo que cubre varias horas solo durante el incidente de alto uso de recursos.

Como podemos ver, en realidad no hay ninguna consulta que informe sobre el uso significativo de datos IO.

También he corrido sp_who2y sp_whoisaciveen la base de datos y realmente no veo nada que me salte a la vista (aunque admito que no soy un experto con estas herramientas).

¿Cómo me doy cuenta de lo que está pasando aquí? No creo que ninguna de mis consultas sobre la aplicación sea la responsable del uso de este recurso y tengo la sensación de que hay un proceso interno ejecutándose en segundo plano en el servidor que lo está matando.

Dado que durante el pico (s) su actividad de registro es mínima, podemos suponer que no está ocurriendo ningún (o mucho) DUI.

Usted menciona en un punto que el pico no afecta el rendimiento, y en otro que sí lo hace. Cual es

También mencionas que esto desaparece después de una operación de escala. Esto tiene sentido ya que es análogo a un reinicio en las instalaciones que matará efectivamente todos los procesos, etc.

¿Asumo correctamente al adivinar que se está accediendo a esta base de datos desde el nivel de aplicación? Si es así, sospecho que sus conexiones no se están cerrando correctamente . Se supone que el recolector de basura se ocupará de estos eventualmente (que no se debe confiar en ellos), pero he visto que esta situación exacta ocurre debido a conexiones no cerradas desde el nivel de aplicación. En nuestro caso, la aplicación estaba tan ocupada que finalmente recibimos errores de conexión concurrentes, que es lo que nos llevó al problema.

Pruebe la siguiente consulta durante el pico:

SELECT
    c.session_id, c.net_transport, c.encrypt_option,
    s.status,
    c.auth_scheme, s.host_name, s.program_name,
    s.client_interface_name, s.login_name, s.nt_domain,
    s.nt_user_name, s.original_login_name, c.connect_time,
    s.login_time
FROM sys.dm_exec_connections AS c
JOIN sys.dm_exec_sessions AS s
    ON c.session_id = s.session_id
ORDER BY c.connect_time ASC

Si estoy en lo correcto, encontrará un montón de registros devueltos con el estado de Sleeping, o peorRunning . Si ese es el caso, tiene problemas aún mayores en el nivel de aplicación.

Podemos depurar aún más esto copiando la base de datos, usando la siguiente consulta (usando el nivel básico para evitar costos excesivos) y monitoreando este comportamiento.

CREATE DATABASE Database1_copy AS COPY OF Database1 ( EDITION = 'basic' );