Alto uso de segmento de trabalho HADR

Por que o número de threads de trabalho de um grupo de disponibilidade em um pool HADR aumentaria muito além do uso mínimo de " normalmente, há de 3 a 10 threads compartilhados " por réplica?

Em um caso, observamos o uso de mais de 300 threads com 3 grupos de disponibilidade e 10 bancos de dados no total. SQL Server 2014 SP1.

Nossos leads são backup na réplica secundária, alta atividade na réplica primária, relatórios na réplica secundária.

Os AGs estão em um datacenter no VMware. No total, com 16 agendadores, os segmentos de trabalho comuns estão abaixo do intervalo de 200. max_dop no servidor é 2.

3 AG, 10 DB, 4 réplicas cada - primário, 2 somente leitura, 1 não legível.
1 secundário é sincronizado, 2 assíncrono
16 vcores em 32 núcleos físicos no cluster grande de vários hosts.
Sem superprovisão.
Outras VMs menores, de 4 a 8 núcleos, são colocadas, mas não pressionam na CPU

Observamos um aumento nos threads de trabalho, resultando em negação de serviço. A atribuição de threads de trabalho à AG é nossa suposição, pois apenas esses threads de trabalho podem ultrapassar o limite.

Abaixo, os links do Blog de engenheiros de campo do SQL Server Premier, lidos no contexto, não oferecem uma resposta completa para mim:

— Alexander Tarasul
fonte

Você pode postar exemplos de captura de tela do que está vendo? Algo parece errado aqui, como se você estivesse consultando threads de trabalho em geral, em vez de especificamente os de AG. (E outros segmentos de trabalho pode atravessar o limite, também, não apenas os AG.)

— Brent Ozar

Estou caçando um problema semelhante. Tenho certeza que eu preguei isso na questão do MaxDop. Estou usando scripts Ola Hallengreens para IndexMaintenance, e a configuração MaxDOP foi definida como NULL. O ponto é: você poderia ter consultas entrando em contato com o MaxDOP 2?

— Kasper Brandenburg

Você conseguiu alguma solução para isso?

— trusha 28/02

-1

Como o seu controlador de domínio está na VM, suspeito que você esteja com um desempenho ruim do disco. Um desempenho ruim do disco pode resultar em tempos de gravação e log mais lentos no secundário, o que pode resultar em um reconhecimento mais lento da réplica secundária na réplica primária (esgotando os threads de trabalho).

A latência do disco na réplica secundária pode causar um aumento no processo de Confirmação de sincronização do HADR, resultando no primário mantendo os segmentos abertos enquanto aguarda o secundário confirmar a transação.

Verifique o log de erros dos Agendadores com deadlock e colete algumas métricas de E / S do PerfMon para ver a latência do disco e o comprimento da fila de discos.

— Rodrigo Nascentes
fonte