Início / dba / Perguntas / 290757
Accepted
Newbie-DBA
Asked: 2021-04-30 11:48:03 +0800 CST

Encadeamento de REDO preso de um grupo de disponibilidade

  • 772

Estamos enfrentando problemas com a flutuação da fila REDO, pois temos uma configuração secundária legível.

Com base no meu entendimento em versões mais recentes do SQL Server, os threads de redo foram tornados paralelos. A versão atual é o SQL Server 2017 em execução na VM com 64 núcleos.

Estou vendo problemas ao selecionar consultas na execução secundária no mesmo cpu/scheduler em que os threads AG estão sendo executados. Estou assumindo que o thread AG produz seu agendador e fica em segundo plano para permitir que outras consultas sejam executadas. E acredito que este seja o problema porque as consultas que chegam parecem estar atingindo o mesmo cpu_id onde os threads AG estão fazendo o trabalho de refazer.

Exemplo abaixo: spid 91 é uma consulta selecionada em cpu_id 6 e ao mesmo tempo spid 123 e 144 threads em execução para AGs conforme encontrado em sys.dm_exec_requests dmv. A fila REDO começa a se acumular quando 91 apareceu.

insira a descrição da imagem aqui

Não sei se existe algum processo que faça suas consultas irem para núcleos diferentes em vez de um em que o thread de AGs possa estar em execução.

  1. Podemos controlar isso para que as consultas atinjam outros agendadores e não um em que o AG esteja trabalhando?

  2. Vejo muitas esperas em PARALLEL_REDO_TRAN_TURN quando as consultas são executadas no secundário enquanto os threads AG estão suspensos. Pode rastrear a ajuda do sinalizador conforme mencionado aqui

  3. Pode haver muitos outros agendadores disponíveis. Não consigo entender por que determinado processo está travado no slot do Numa. Eu acho que as versões mais recentes têm todos os numas suaves habilitados, então isso faz um balde de 8 numas suaves. 8*8 agendadores para 64 disponíveis. Desabilitar o numa soft é uma boa ideia aqui?

O isolamento de banco de dados é RCSI, mas não acho que isso importe aqui porque internamente ele foi alterado para instantâneo com base no design de secundários legíveis.

sql-server performance

1 respostas

  1. Best Answer

    Embora isso possa não ser a resposta que você está procurando, pois exige uma migração no final, você pode tentar executar sua carga de trabalho no SQL Server 2019 para poder usar " SQL Server 2019 Intelligent Performance -Worker Migration " ou também comumente chamado de Worker Roubando.

    A migração do trabalhador (AKA “roubo do trabalhador”) permite que um agendador SOS ocioso migre um trabalhador da fila executável de outro agendador no mesmo nó NUMA e retome imediatamente a tarefa do trabalhador migrado. Esse aprimoramento fornece um uso mais balanceado da CPU e reduz a quantidade de tempo que as tarefas de execução longa passam na fila executável.

    Uma tarefa de longa execução habilitada para migração do trabalhador não está mais vinculada a um agendador fixo. Em vez disso, ele frequentemente se moverá entre agendadores dentro do mesmo nó NUMA, o que naturalmente resulta em agendadores menos carregados. Juntamente com o mecanismo de fator de carga existente, a migração do trabalhador fornece ao SQL Server uma solução enriquecida para uso balanceado da CPU.

    Fonte

    O Parallel Redo está qualificado para migração de trabalhadores, conforme observado na mesma fonte :

    No SQL Server 2019, os trabalhadores associados às tarefas de refazer paralelas do grupo de disponibilidade são habilitados para migração do trabalhador para resolver um problema de contenção do agendador comumente observado entre tarefas de refazer em réplicas secundárias.

    Ao migrar para o SQL Server 2019, esse recurso é habilitado por padrão.

    Adição

    Vejo muitas esperas em PARALLEL_REDO_TRAN_TURN quando as consultas são executadas no secundário enquanto os threads AG estão suspensos. O sinalizador de rastreamento 3459 pode ajudar?

    Esse sinalizador de rastreamento pode fornecer benefícios se as consultas em execução no secundário não puderem ser adaptadas (por exemplo, consultas de longa execução no secundário com tempo reduzido). Mas pode haver outros motivos, como divisões de página frequentes.

    Uma maneira de ver se a execução do serial de thread de redo é benéfica para sua configuração é examinar as PARALLEL_REDO_TRAN_TURNestatísticas de espera, mas você sempre deve compará-las com outras informações, como aumento/diminuição do tamanho da fila de redo no arquivo .

    Lembre-se de habilitar esse traceflag, pois o desempenho de redo pode ser prejudicado por ser serial em vez de paralelo.

    • 3

relate perguntas