Aumento substancial sustentado em Gravações Lógicas para todos os planos e bancos de dados em uma Instância Gerenciada do Azure

Temos uma instância gerenciada com 12 ou mais dbs que suportam o mesmo aplicativo em 2x clientes. Isso está sendo executado em uma instância gerenciada por sql de 4 núcleos, mas quase exatamente à meia-noite, hora local, cerca de 2 semanas atrás, o desempenho caiu substancialmente. Isso foi visto como CPU excessiva (aumentando rapidamente para 100% quando o trabalho do usuário começou às 6h daquele dia) e a instância foi migrada para 8 núcleos por volta do meio-dia.

Em 8 núcleos, as métricas do Azure para CPU média e de pico se estabilizaram nos mesmos níveis da instância de 4 núcleos e permaneceram semelhantes (portanto, o gráfico tem a mesma forma seguindo a demanda do usuário na pré e pós-migração).

Isso sugere que o serviço agora é 1/2 tão eficiente quanto antes do pico de 100% da CPU.

A análise mostra que a espera dominante de longe é SOS_scheduler_yield. Ao mesmo tempo, notamos que quase todas as consultas que verificamos no repositório de consultas registram um grande aumento nas Gravações Lógicas no ponto da meia-noite em que vemos a CPU começando a aumentar.

Eu me perguntei se algo de Paul Randall sobre o comprometimento excessivo da VM pode ser relevante https://www.sqlskills.com/blogs/paul/increased-sos_scheduler_yield-waits-on-virtual-machines/ no entanto, não acho que isso se encaixe na assinatura para aumento de Gravação Lógica.

Então, isso pode ser de 10k gravações para 1M+, ou seja, 2 ordens de magnitude.

Não estamos vendo consultas de longa duração, sem bloqueio - o sistema atende a muitas consultas curtas.

Correspondendo ao alto número de gravações lógicas, o PLE caiu no chão - agora mede em minutos se tivermos sorte, segundos se não.

a carga de trabalho OLTP (demanda do usuário) permanece inalterada em relação a antes, assim como os volumes de dados.

Parece um pouco com planos obsoletos, mas em grande escala - ou como se o sqlserver decidisse descartar uma vez dos caminhos do otimizador da implementação da consulta.

O que é estranho é como alguns planos para a mesma consulta mostram gravações lógicas inalteradas antes/depois, mas outros planos para essa consulta mostram esse grande pico, mesmo que o ID do plano seja o mesmo. E isso não é "consulta de um problema" - esse padrão é exibido para quase todas as consultas que analisamos. Ou eles têm um único plano e ele aumentou, ou eles têm alguns planos (parametrização) e alguns aumentaram e outros não. Ainda não encontramos um padrão para eles.

Uma revisão de DBA externa realmente não revelou nada além de estatísticas um pouco obsoletas (ainda quando consultamos estatísticas obsoletas, as com alta taxa de alteração são todas atualizadas nos últimos dias e eu ficaria um pouco surpreso se essa fosse a causa subjacente através de uma ampla gama de consultas.

Ele foi escalado para o MS, mas pensei em postar caso alguém tivesse experimentado algo semelhante (grande aumento repentino nas gravações lógicas), principalmente no Azure. Da forma como o gráfico da CPU lê, estamos usando a mesma % de CPU avg/max antes e depois do aumento do núcleo, é quase exatamente o dobro do consumo de CPU. O que me faz pensar que é um fator que afeta o sqlserver, mas não diretamente no db.

Obrigado por ler até aqui e todas as sugestões úteis!