Quem está usando meus threads de trabalho? SQL Server 2014 - HADR

Recentemente, tivemos um problema em nosso ambiente HADR do SQL Server 2014, em que um dos servidores ficou sem threads de trabalho.

Recebemos a mensagem:

O conjunto de encadeamentos dos Grupos de Disponibilidade AlwaysOn não pôde iniciar um novo encadeamento de trabalho, porque não há encadeamentos de trabalho disponíveis suficientes.

Eu já abri outra pergunta, para obter uma declaração que (pensei) deveria me ajudar a analisar o problema ( é possível ver qual SPID usa qual agendador (thread de trabalho)? ). Embora eu tenha agora a consulta para localizar os threads que estão usando o sistema, não entendo por que o servidor ficou sem threads de trabalho.

Nosso ambiente é o seguinte:

• 4 Windows Server 2012 R2
• SQL Server 2014 Enterprise
• 24 processadores -> 832 threads de trabalho
• 256 GB de RAM
• 12 Grupos de Disponibilidade (geral)
• 642 bancos de dados (geral)

Portanto, o servidor que teve o problema teve a seguinte configuração:

• 5 grupos de disponibilidade (3 primário / 2 secundário)
• 325 Bancos de Dados (127 Primário / 198 Secundário)
• MAXDOP = 8
• Cost Threshold for Parallelism = 50
• O plano de energia está definido como "Alto desempenho"

Para "resolver" o problema, falhamos manualmente em um Grupo de Disponibilidade no servidor secundário. A configuração desse servidor é agora:

• 5 grupos de disponibilidade (2 primário / 3 secundário)
• 325 Bancos de Dados (77 Primário / 248 Secundário)

Estou monitorando os threads disponíveis com esta declaração:

declare @max int
select @max = max_workers_count from sys.dm_os_sys_info

select 
    @max as 'TotalThreads',
    sum(active_Workers_count) as 'CurrentThreads',
    @max - sum(active_Workers_count) as 'AvailableThreads',
    sum(runnable_tasks_count) as 'WorkersWaitingForCpu',
    sum(work_queue_count) as 'RequestWaitingForThreads' ,
    sum(current_workers_count) as 'AssociatedWorkers'
from  
    sys.dm_os_Schedulers where status='VISIBLE ONLINE'

Normalmente, o servidor tem entre 250 e 430 threads de trabalho disponíveis, mas quando o problema começou, não havia mais trabalhadores.

Hoje, do nada, os trabalhadores disponíveis caíram de 327 para 50, mas apenas por um minuto e voltaram para cerca de 400.

Eu já vi a outra pergunta ( alto uso de threads de trabalho HADR ), mas isso não me ajuda.

Nosso sistema ficou estável por mais de um ano sem problemas. Não tivemos nenhum failover ou outra alteração importante na distribuição dos bancos de dados.

Estamos usando "Confirmação síncrona" entre as réplicas. Pelo meu entendimento, não há compactação envolvida, consulte Ajustar compactação para o grupo de disponibilidade na documentação.

Alguém tem uma idéia do que está usando todos os threads de trabalho?

EDIT: Encontrou esta página onde há muitas informações sobre exatamente esses problemas http://www.techdevops.com/Article.aspx?CID=24

_{Resposta do wiki da comunidade :}

Você tem um alto número de bancos de dados em grupos de disponibilidade, e é aí que seus segmentos estão indo. Há muita coisa envolvida nos custos de compactação, criptografia e transporte. Tente desativar a compactação, isso reduzirá o uso de threads em cerca de um terço (dependendo da contagem de réplicas).

A pergunta está marcada como SQL Server 2014, que por padrão usará a compactação. O SQL Server 2016, por padrão, não usará compactação para sincronização.

Pode ser necessário aumentar os threads de trabalho na instância ou melhor: equilibrar os mais ativos e os inativos em vários servidores. Consulte a consulta do grupo de disponibilidade AlwaysON relacionada à Perguntas e Respostas muito lenta .

Você também pode achar que é um aplicativo que não consegue fechar solicitações corretamente. Isso pode resultar em muitas sessões de sono por aí (que consomem trabalhadores).

O número de threads realmente usados ​​depende de quão ativos os bancos de dados estão. Você pode ter 1.000 bancos de dados e, se a maioria estiver inativa 95% das vezes, não terá problemas. Parece que seus bancos de dados se tornaram ativos com mais frequência e consumiram mais tópicos. Esse é o longo e curto disso.