Il y a quelques mois, j'ai fait face à une situation similaire dans laquelle le paramètre MAXDOP était par défaut et une requête de fuite a épuisé tous les threads de travail.
Comme l'a souligné Remus, cela s'appelle la famine du thread de travail .
Un vidage de mémoire sera créé sur votre serveur lorsque cette condition se produira.
Si vous utilisez 2008R2 + SP1 et plus, vous sys.dm_server_memory_dumps
obtiendrez également l'emplacement du fichier de vidage.
Revenons maintenant au problème:
Il y a 1 thread de surveillance du planificateur par nœud NUMA et puisque vous avez 2 nœuds NUMA, il y aura 2 threads de surveillance du planificateur qui sont responsables de la vérification de la santé de tous les planificateurs toutes les 60 secondes pour ce nœud NUMA particulier tout en s'assurant que le planificateur est bloqué ou ne pas.
Chaque fois qu'une nouvelle demande de travail est extraite de la file d'attente de travail des planificateurs, le compteur des processus de travail est incrémenté. Donc, si le planificateur a une demande de travail en file d'attente et n'a pas traité l'une des demandes de travail en 60 secondes, le planificateur est considéré comme bloqué.
En raison d'une requête de fuite ou d'un parallélisme étendu, une condition de threads de travail commence à être épuisée car tous les threads sont occupés par cette requête de fuite unique ou un blocage prolongé excessif et aucun travail ne peut être effectué à moins que ce processus offensant ne soit tué.
Votre meilleur pari est de régler d'abord votre paramètre Max Degree of Parallelism . Par défaut 0
, SQL Server peut utiliser tous les processeurs disponibles pour le traitement parallèle et en épuisant tous les threads de travail.
De nombreuses raisons peuvent conduire à l'épuisement des threads de travail:
- Longues chaînes de blocage étendues entraînant le manque de threads de travail dans SQL Server
- Parallélisme étendu conduisant également à l'épuisement des threads de travail
- Attente prolongée pour tout type de «verrou» - verrous tournants, verrous. Un spinlock orphelin en est un exemple.
Reportez-vous à ma réponse ici qui vous montrera comment vous pouvez calculer la valeur MAXDOP pour votre instance de serveur.
En outre, nous vous recommandons vivement de commencer à collecter des informations sur les statistiques d'attente sur votre instance de serveur de base de données.
max degree of parallelism
configuré et combien de processeurs avez-vous actuellement sur le serveur avec la configuration NUMA? Vous pouvez utiliser àcoreinfo.exe
partir de sysinternals pour connaître le nombre de processeurs et la configuration NUMA.