Por que meu banco de dados SQL do Azure (SQL Server) está ficando sobrecarregado com E / S de dados por períodos de cada vez? [fechadas]

Estou executando um banco de dados SQL do Azure na edição S2 (50 DTUs). O uso normal do servidor geralmente trava em torno de 10% de DTU. No entanto, este servidor entra regularmente em um estado em que enviará o uso de DTU do banco de dados para 85-90% por horas. De repente, ele volta ao uso normal de 10%.

As consultas no servidor a partir do aplicativo ainda parecem estar operando rapidamente durante esse estado sobrecarregado.

Eu posso escalar o servidor de S2 => qualquer coisa (S3 por exemplo) => S2 e parece limpar qualquer estado em que ele esteja pendurado. Mas, algumas horas depois, ele repetirá novamente o mesmo ciclo de estado sobrecarregado. Outra coisa estranha que notei é que, se eu executar esse servidor em um plano S3 (100 DTU) 24/7, não observarei esse comportamento. Parece apenas ocorrer quando eu reduzi o escalonamento do banco de dados para um plano S2 (50 DTU). No plano S3, estou sempre sentado com 5 a 10% de uso de DTU. Obviamente subutilizado.

Fiz check-in nos relatórios de consulta SQL do Azure à procura de consultas não autorizadas, mas realmente não vejo nada de incomum e mostra minhas consultas usando recursos, como seria de esperar.

Como podemos ver aqui, porém, o uso é todo proveniente do Data IO. Se eu alterar o relatório de desempenho aqui para mostrar as principais consultas de IO de dados pelo MAX, vemos o seguinte:

Observar essas questões de longa duração parece apontar para atualizações de estatísticas. Não é realmente nada do meu aplicativo. Por exemplo, a consulta 16302 mostra:

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)

Mas, novamente, o relatório também mostra que essas consultas estão usando apenas uma pequena porcentagem do uso de Data IO no servidor (<4%). Também executo atualizações de estatísticas (e reconstruções de índice) em todo o banco de dados semanalmente, como parte de sua manutenção regular.

Aqui está outro relatório que mostra consultas de E / S de dados MAX por um período de tempo que cobre várias horas apenas durante o incidente de alto uso de recursos.

Como podemos ver, não há realmente nenhuma consulta que relate o uso significativo de IO de dados.

Também corri sp_who2e sp_whoisaciveno banco de dados e realmente não vejo nada pulando em mim (embora eu admita que não sou especialista nessas ferramentas).

Como faço para descobrir o que está acontecendo aqui? Não acho que nenhuma das minhas consultas de aplicativos seja responsável por esse uso de recursos e sinto que há algum processo interno em execução em segundo plano no servidor que o está matando.

Dado que durante os picos, sua atividade de log é mínima, podemos assumir que não há (ou muita) DUI em andamento.

Você menciona em um momento que o pico não afeta o desempenho e em outro que afeta. Qual é?

Você também mencionou que isso desaparece após uma operação de balança. Isso faz sentido, pois é análogo a uma reinicialização no local que efetivamente mata todos os processos, etc.

Suponho corretamente ao adivinhar que esse banco de dados está sendo acessado a partir da camada do aplicativo? Nesse caso, suspeito que suas conexões não estão sendo fechadas corretamente . O coletor de lixo deve cuidar disso eventualmente (o que não deve ser considerado), mas vi essa situação exata ocorrer devido a conexões não fechadas do nível do aplicativo. No nosso caso, o aplicativo estava tão ocupado que, eventualmente, recebemos erros de conexão simultâneos, o que nos levou ao problema.

Tente a seguinte consulta durante o 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

Se eu estiver correto, você encontrará vários registros retornados com o status de Sleeping, ou piorRunning . Se for esse o caso, você terá problemas ainda maiores no nível do aplicativo.

Podemos depurar ainda mais isso copiando o banco de dados, usando a consulta a seguir (usando a camada básica para evitar custos excessivos) e monitorando esse comportamento.

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