web-dev-qa-db-fra.com

SQL Server connaît THREADPOOL attend tout en ayant beaucoup de travailleurs disponibles

J'ai récemment jeté un œil aux attentes cumulées de pool de threads de production de SQL Server, et cela vaut littéralement des jours d'attente. J'ai donc commencé à creuser.

Je suis sur un serveur 32 cœurs, 64 bits (fonctionnant sur EC2). Le nombre maximal de travailleurs est correctement défini sur 0 dans la configuration et le DMV suivant indique le nombre attendu correct:

SELECT max_workers_count FROM sys.dm_os_sys_info

Output: 960

En regardant mon nombre total de travailleurs, j'en vois rarement plus de 300 à 400:

SELECT count(*) FROM sys.dm_os_workers

Output: 372

Et pourtant, si je lance le DMV suivant, j'ai toujours des threads répertoriés:

SELECT * FROM sys.dm_os_waiting_tasks
WHERE wait_type = 'THREADPOOL'

Waiting Tasks -- Threadpool

SELECT dow.state , dow.is_preemptive , dow.is_sick , dow.is_in_polling_io_completion_routine , [Num Workers] = COUNT(1) 
FROM sys.dm_os_workers dow 
GROUP BY dow.state , dow.is_preemptive , dow.is_sick , dow.is_in_polling_io_completion_routine;

enter image description here

Les attentes en millisecondes sont généralement assez courtes, de 20 à 200 ms en général, et elles disparaissent rapidement également, mais elles s'ajoutent au chiffre cumulé global du pool de threads. Ils n'ont également jamais de sessions de blocage.

Je suis perplexe quant à la raison pour laquelle quelque chose rencontre une attente de thread quand j'ai autant de travailleurs disponibles. Les centaines de travailleurs disponibles ne devraient-ils pas traiter ces demandes instantanément sans que les threads ne soient mis en file d'attente?

J'apprécierais toute entrée ou direction ici.

Version SQL Server: SQL Server 2016 (SP2-CU8) (KB4505830) - 13.0.5426.0 (X64) Enterprise Edition: (64 bits) sur Windows Server 2016 Datacenter 10.0 (Build 14393:) (hyperviseur)

sql-serversql-server-2016wait-types
6
Mike P.

Si vous avez degré maximal de parallélisme défini sur zéro, qui est la valeur par défaut, les requêtes susceptibles de bénéficier du parallélisme consomment 32 threads. Avec le nombre de travailleurs défini sur 960, là encore la valeur par défaut pour votre configuration, vous ne pouvez exécuter que 30 requêtes parallèles simultanées.

Je recommanderais définissant le degré maximum de parallélisme à quelque chose de sain, comme 8.

3
Max Vernon