Estou observando um log_send_rate baixo em minha configuração de AG distribuído. Eu entendo que o AG usa o fluxo de log e, portanto, suponho que não deve ter nada a ver com dados, mas queria saber se isso tem algo a ver com os dados que ele está transmitindo também e não apenas com os recursos do sistema operacional (rede, E/S)?
Métricas básicas para consideração:
- SQL Server 2019-CU16
- RAM de origem 1,5 TB, 48 CPU <> RAM de destino 128 GB, 48 CPU - A diferença na memória desempenha algum papel aqui?
- Ambos os servidores estão no mesmo DC, a latência do ping é <1ms. O servidor de destino é VM.
- O teste ROBOCOPY mostra uma taxa de transferência de arquivos de ~100 MB/s
- Quando atividades de geração de log de transações altas (como manutenção ou criação de índice) são enviadas para outra réplica - ele é transferido com uma taxa máxima de 20 MB/s (o que não é esperado). É quando o log_send_queue se acumula.
- A taxa de REDO do outro lado é boa, nenhuma fila de REDO se acumulando lá.
No AG de origem, não vejo nada para o contador 'Bytes Enviados para Transporte/Sec', então não posso determinar se isso é um gargalo ou não.
Por favor, sugira se eu perdi alguma coisa que eu deveria ter incluído.
Um ótimo recurso para investigar isso é a postagem de Sean Gallardy: Network Throughput Hysteria
A primeira coisa seria certificar-se de que você está comparando coisas equivalentes. Da postagem:
Sean recomenda usar o ntttcp para medir a taxa de transferência de rede de um único thread e um único núcleo. Fazer isso lhe dará uma linha de base melhor para comparar os 20 MB/s.
Se ainda houver uma lacuna muito grande que precise ser explicada, talvez seja necessário aprofundar exatamente onde no processo a latência está ocorrendo. Aqui está um excelente artigo sobre como fazer isso no suporte da Microsoft:
Solucionando problemas de latência de movimentação de dados entre grupos de disponibilidade AlwaysOn de confirmação síncrona
Como você pode ver no diagrama, há muitas etapas no processo de transmissão e proteção de blocos de log para um secundário. A desaceleração pode estar em qualquer lugar lá. Há um link para uma ferramenta gratuita no final dessa postagem do blog que analisará os rastreamentos de eventos estendidos para você FYI.
Quanto aos dados que você forneceu:
A diferença de memória no destino não é ideal do ponto de vista de failover (sua carga de trabalho pode ser executada efetivamente com 1/12 da RAM?), mas como você não está vendo uma fila REDO alta, ficaria surpreso se ela estivesse contribuindo para a fila de envio se acumula.
É bom que as réplicas estejam no mesmo DC - isso torna menos provável que a latência geral da rede seja a culpada (você não está tentando replicar para a nuvem ou do outro lado do mundo).
E, novamente, o teste ROBOCOPY pode não ser uma boa comparação.
Alguns fatores adicionais a serem considerados para a baixa taxa de envio de log do Grupo de Disponibilidade do SQL Server.
Este artigo fornece uma boa descrição e etapas de solução de problemas para várias condições que podem resultar em controle de fluxo do Grupo de Disponibilidade e taxas de envio de log abaixo do esperado.
Causas comuns e soluções de solução de problemas para a latência de sincronização de dados do SQL AG
Se o Grupo de Disponibilidade for síncrono, a compactação antes do envio será desabilitada por padrão (economize um pouco de tempo e um pouco de CPU, use um pouco mais de largura de banda). Se o Grupo de Disponibilidade for assíncrono, a compactação antes do envio será habilitada por padrão (demore um pouco mais, use um pouco mais de CPU para reduzir as necessidades de largura de banda). Para uma determinada carga de trabalho, a compensação pode não funcionar favoravelmente. Os sinalizadores de rastreamento estão disponíveis para substituir o estado padrão de compactação antes do envio para grupos de disponibilidade síncronos e assíncronos.
Sinalizações de rastreamento para compactação do grupo de disponibilidade
Para SQL Server vms, sempre recomendo aumentar os buffers de recebimento TCP para os adaptadores de rede. Se esta for uma VM VMware, recomendo fortemente o adaptador de rede vmxnet3. Para cada adaptador vmxnet3 em uma VM, a diferença líquida no uso de vRAM dentro da vm é inferior a 18 mb quando os parâmetros "small rx buffers" e "rx ring #1 size" são aumentados dos valores padrão para os valores máximos. (Estes são os parâmetros a serem alterados se o parâmetro "Jumbo Packet" tiver o valor "Padrão 1500" ou algo próximo a 1500 como 1512. Se "Jumbo Packet" for 8000, deve-se encontrar parâmetros de recebimento TCP de pacote jumbo para modificar.) No caso de um Grupo de Disponibilidade, garantindo o recurso de recebimento TCP adequado no secundário, reduz a lentidão da transmissão devido à perda de pacotes ao longo do caminho.
Grande perda de pacotes no sistema operacional convidado usando VMXNET3 no ESXi (2039495)
Certifique-se de que o plano de energia seja de alto desempenho no lado de envio e recebimento do Grupo de Disponibilidade. Para o destino secundário da VM, pode ser necessário verificar no nível da VM e do host. Para processadores mais antigos, se menos da metade dos núcleos em um soquete estiverem ocupados, todos os núcleos no soquete poderão ficar mais lentos (em vez de ajustar a energia de núcleos individuais como em processadores posteriores). E quando os núcleos ficam mais lentos, outros componentes, como adaptadores de rede, também podem ficar mais lentos (até mesmo os tempos de acesso à memória podem ficar mais lentos com algumas implementações de planos de energia).
Por fim, embora a taxa de envio de log seja menor que a desejada, para essa carga de trabalho ela pode estar no pico. Muitos sites evitam grandes recompilações de índice tanto quanto possível em Grupos de Disponibilidade devido ao estresse, concentrando-se em reorganizações de índice.
Muito obrigado @sqL_handLe e @Josh Darnell por seus comentários sobre isso.
Mas a causa real nesse problema específico foi a incompatibilidade de tamanho do setor de bytes na origem (512) e no destino (4096).
Ao verificar qual estágio do AG estava desacelerando o processo usando a aglatency-report-tool ( porque para AG distribuído não consigo gerar relatório de latência do SSMS ), percebi que estava no destino e não na origem!
Registro de erro verificado no destino e foi preenchido com erros desalinhados de E/S. ( Eu sei que deveria ter visto isso antes :P )
De acordo com este artigo - isso pode significar
Então eu peguei alguma ajuda de artigos ( MS tech community & KB3009974 ) para chegar à conclusão de adicionar o TF 1800 ao parâmetro de inicialização na fonte, reiniciei os serviços SQL e log_send_rate apenas aumentou até 200 MB/s.
É claro que os pontos que você mencionou foram muito úteis para eu chegar à causa raiz desse problema e agradeço por isso!