O curioso caso de HADR_SYNC_COMMIT aguarda

Estamos percebendo um padrão interessante de HADR_SYNC_COMMITespera em nosso ambiente. Temos uma réplica de três; uma primária, uma secundária de sincronização e uma secundária assíncrona em um datacenter e acabamos de adicionar mais três réplicas ASYNC em outro datacenter (a aproximadamente 2.400 milhas de distância).

Desde então, começamos a notar um enorme aumento nas HADR_SYNC_COMMITesperas. Quando olhamos para as sessões ativas, vemos várias COMMIT TRANSACTIONconsultas aguardando a réplica SYNC

A partir da captura de tela, podemos ver claramente que há um atraso no HADR_SYNC_COMMITdia 29 de junho e, eventualmente, eliminamos 'duas' das três réplicas assíncronas no datacenter remoto em algum momento do meio-dia de 1º de julho. Isso diminuiu consideravelmente o tempo de espera.

O que verificamos até agora - fila de envio de log, fila de refazer, último tempo de proteção e último tempo de confirmação nas réplicas remotas. Temos rajadas contínuas de pequenas transações durante o horário comercial e, portanto, as filas de envio são muito pequenas em um determinado carimbo de data / hora (entre 60 KB e 1 MB).
As réplicas remotas estão quase sincronizadas, há muito pouca diferença entre o último tempo de confirmação e o último tempo de proteção para qualquer lsn individual nas réplicas.

O canal de rede é 10G e modificamos o tamanho do buffer de transmissão de 256 megs para 2 GB, isso foi feito sob a suposição de que a rede estava descartando pacotes e os transmitindo novamente; de qualquer maneira que não pareceu ajudar muito.

Então, eu estou querendo saber o que as réplicas ASYNC têm a ver com HADR_SYNC_COMMITesperas? A réplica SYNC não deve depender sozinha desse tipo de espera, o que estou perdendo aqui?

Primeiro, a descrição do evento de espera referente à sua pergunta é:

Aguardando processamento de confirmação de transação para os bancos de dados secundários sincronizados para proteger o log. Essa espera também é refletida pelo contador de desempenho Atraso na transação. Esse tipo de espera é esperado para grupos de disponibilidade sincronizados e indica o tempo para enviar, gravar e confirmar o log nos bancos de dados secundários.

https://msdn.microsoft.com/en-us/library/ms179984.aspx

Ao analisar a mecânica dessa espera, você tem os blocos de log sendo transmitidos e protegidos, mas a recuperação não está concluída nos servidores remotos. Sendo esse o caso, e como você adicionou réplicas adicionais, é lógico que o seu HADR_SYNC_COMMIT pode aumentar devido ao aumento nos requisitos de largura de banda. Nesse caso, Aaron Bertrand está exatamente correto em seus comentários sobre a questão.

Fonte: http://blogs.msdn.com/b/psssql/archive/2013/04/26/alwayson-hadron-learning-series-hadr-sync-commit-vs-writelog-wait.aspx

Analisando a segunda parte da sua pergunta sobre como essa espera pode estar relacionada a lentidões de aplicativos. Acredito que isso seja uma questão de causalidade. Você está observando suas esperas aumentando e uma reclamação recente do usuário e chegando à conclusão potencialmente incorreta de que os dois têm um relacionamento quando isso pode não ser o caso. O fato de você ter adicionado arquivos tempdb e seu aplicativo ter me respondido mais indica que você pode ter tido alguns problemas de contenção subjacentes que poderiam ter sido exacerbados pela sobrecarga adicional da sobrecarga implícita no nível de isolamento de captura instantânea quando um banco de dados está em um grupo de disponibilidade. Isso pode ter tido pouco ou nada a ver com suas esperas HADR_SYNC_COMMIT.

Se você quiser testar isso, poderá utilizar um rastreamento de evento estendido que observe o XEvent hadr_db_commit_mgr_update_harden na sua réplica primária e obtenha uma linha de base. Depois de ter sua linha de base, você poderá adicionar suas réplicas uma de cada vez e ver como o rastreamento é alterado. Recomendamos que você use um arquivo que resida em um volume que não contenha bancos de dados e defina uma sobreposição e tamanho máximo. Ajuste o filtro de duração conforme necessário para reunir eventos que correspondam às suas esperas, para que você possa solucionar mais problemas e correlacionar isso com outras equipes que precisem estar envolvidas.

CREATE EVENT SESSION [HADR_SYNC_COMMIT-Monitor] ON SERVER  -- Run this on the primary replica 
ADD EVENT sqlserver.hadr_db_commit_mgr_update_harden(
    WHERE ([delay]>(10))) -- I strongly encourage you to use the delay filter to avoid getting too many events back, this is measured in milliseconds
ADD TARGET package0.event_file(SET filename=N'<YourFilePathHere>')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO