Qui utilise mes threads de travail? SQL Server 2014 - HADR

Nous avons récemment rencontré un problème sur notre environnement HADR SQL Server 2014, où l'un des serveurs était à court de threads de travail.

Nous avons reçu le message:

Le pool de threads pour les groupes de disponibilité AlwaysOn n'a pas pu démarrer un nouveau thread de travail car il n'y a pas suffisamment de threads de travail disponibles.

J'ai déjà ouvert une autre question, pour obtenir une déclaration qui (je pensais) devrait m'aider à analyser le problème ( est-il possible de voir quel SPID utilise quel planificateur (thread de travail)? ). Bien que j'ai maintenant la requête pour trouver les threads qui utilisent le système, je ne comprends pas pourquoi ce serveur a manqué de threads de travail.

Notre environnement est le suivant:

• 4 Windows Server 2012 R2
• SQL Server 2014 Enterprise
• 24 processeurs -> 832 threads de travail
• 256 Go de RAM
• 12 groupes de disponibilité (global)
• 642 bases de données (global)

Ainsi, le serveur qui a rencontré le problème avait la configuration suivante:

• 5 groupes de disponibilité (3 primaires / 2 secondaires)
• 325 bases de données (127 primaires / 198 secondaires)
• MAXDOP = 8
• Cost Threshold for Parallelism = 50
• Le plan d'alimentation est défini sur "Haute performance"

Pour «résoudre» le problème, nous avons manuellement fait basculer un groupe de disponibilité sur le serveur secondaire. La configuration de ce serveur est maintenant:

• 5 groupes de disponibilité (2 primaires / 3 secondaires)
• 325 bases de données (77 primaires / 248 secondaires)

Je surveille les discussions disponibles avec cette déclaration:

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'

Normalement, le serveur dispose d'environ 250 à 430 threads de travail disponibles, mais lorsque le problème a commencé, il n'y avait plus de travailleurs.

Aujourd'hui, de nulle part, les travailleurs disponibles sont passés de 327 à 50, mais seulement pendant une minute, puis sont remontés à environ 400.

J'ai déjà vu l'autre question ( utilisation élevée du thread de travail HADR ) mais cela ne m'aide pas.

Notre système est resté stable pendant plus d'un an sans aucun problème. Nous n'avons eu aucun basculement ou autre changement majeur dans la distribution des bases de données.

Nous utilisons la «validation synchrone» entre les répliques. D'après ma compréhension, aucune compression n'est impliquée, voir Ajuster la compression pour le groupe de disponibilité dans la documentation.

Quelqu'un at-il une idée de ce qui utilise tous les threads de travail?

EDIT: Trouvé cette page où il y a beaucoup d'informations sur exactement ces problèmes http://www.techdevops.com/Article.aspx?CID=24

_{Réponse du wiki communautaire :}

Vous avez un grand nombre de bases de données dans les groupes de disponibilité, c'est là que vont vos threads. Les coûts de compression, de chiffrement et de transport sont très impliqués. Essayez de désactiver la compression, cela réduira votre utilisation de thread d'environ un tiers (en fonction du nombre de répliques).

La question est étiquetée SQL Server 2014, qui utilisera par défaut la compression. SQL Server 2016, par défaut, n'utilisera pas la compression pour la synchronisation.

Vous devrez peut-être augmenter les threads de travail sur l'instance, ou mieux: équilibrer les plus actifs et les plus inactifs sur plusieurs serveurs. Reportez-vous à la requête de groupe de disponibilité AlwaysON relative aux questions et réponses très lente .

Vous pouvez également constater qu'il s'agit d'une application qui ne parvient pas à fermer correctement les demandes. Cela peut entraîner de nombreuses séances de sommeil (qui consomment des travailleurs).

Le nombre de threads réellement utilisés dépend de l’activité des bases de données. Vous pourriez avoir 1 000 bases de données et, si la plupart sont inactives 95% du temps, vous n'aurez aucun problème. Il semble que vos bases de données soient devenues plus actives et aient consommé plus de vos threads. C'est le long et le court.