Nous avons récemment eu un problème sur notre environnement HADR SQL Server 2014, où l'un des serveurs a manqué de threads de travailleurs. J'ai le message:
Le piscine de thread pour les groupes de disponibilité Tomyon n'a pas pu démarrer un nouveau fil de travailleur car il n'y a pas assez de threads de travailleurs disponibles
Bien que nous ayons pu "résoudre" le problème en déplaçant l'un des groupes de disponibilité à un autre serveur, je me demandais s'il est possible de voir quelles requêtes s'exécutent sur quel planificateur (ou travailleur ou tâche).
Avec la requête suivante, je suis capable de voir combien de travailleurs sont disponibles, en cours d'utilisation et en attente de ressources:
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'
Et avec la requête suivante, je suis capable de voir quels travailleurs sont en cours sur lesquels la CPU (Core):
SELECT *
FROM sys.dm_os_Schedulers s --> Prozessoren Kerne
JOIN sys.dm_os_workers w ON w.scheduler_address = s.scheduler_address
JOIN sys.dm_os_tasks t ON t.task_address = w.task_address
WHERE s.status = 'VISIBLE ONLINE'
AND s.cpu_id = 2
Y a-t-il un moyen de trouver qui Spid (et à la fin quelle question) fonctionne sur quel fil?
Je cherchais déjà un moment et j'ai trouvé des informations intéressantes sur la connexion entre les planificateurs, les travailleurs et les threads, mais rien qui m'a vraiment montré si cela est possible:
J'aimerais voir quelle base de données utilise tant de threads de travailleurs. Nous avons quelques bases de données qui (à mon avis) n'appartiennent pas au serveur de production. Quand je vérifie sys.dm_exec_requests
il semble ne pas continuer à continuer.
L'environnement est exécuté dans la même configuration pendant plus d'une an sans problèmes. Le serveur en question comporte 24 processeurs et 5 AIM sur celui-ci, avec un total de 325 bases de données. 3 AGS sont primaires. Pour contourner le problème, nous avons échoué à un AG avec 50 bases de données de ce serveur au secondaire.
Merci à Solomon Rutzky :
Avez-vous essayé de corréler à la
scheduler_id
colonne danssys.dm_exec_requests
?
J'ai pu obtenir les informations que je cherchais.
Avec cette requête, je peux voir quelle session utilise quel CPU_ID (planificateur):
SELECT
s.cpu_id,
s.status,
db_name(r.database_id) as [databaseName],
w.last_wait_type,
w.return_code,
t.task_state,
t.pending_io_count,
t.session_id,
r.sql_handle
FROM sys.dm_os_Schedulers s
JOIN sys.dm_os_workers w
ON w.scheduler_address = s.scheduler_address
JOIN sys.dm_os_tasks t
ON t.task_address = w.task_address
JOIN sys.dm_exec_requests r
ON r.scheduler_id = s.scheduler_id
order by 1,3
Pour obtenir les déclarations SQL qui fonctionnent, je change la requête en:
SELECT
s.cpu_id,
s.status,
db_name(r.database_id) as [databaseName],
w.last_wait_type,
w.return_code,
t.task_state,
t.pending_io_count,
t.session_id,
r.sql_handle,
te.text
FROM sys.dm_os_Schedulers s
JOIN sys.dm_os_workers w
ON w.scheduler_address = s.scheduler_address
JOIN sys.dm_os_tasks t
ON t.task_address = w.task_address
JOIN sys.dm_exec_requests r
ON r.scheduler_id = s.scheduler_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) te
order by 1,3
Mais cela ne me donne que (évidemment) les tâches qui ont une SQL_HANDLE.
Il semble que la plupart des threads sur ce serveur soient utilisés par le système lui-même pour tout garder en synchronisation. La plupart des travailleurs sont utilisés comme "emplois système". Le last_wait_type
de ces tâches est principalement REDO_THREAD_PENDING_WORK
ou alors HADR_WORK_QUEUE
.
Bien que j'ai la réponse que je cherchais, je n'ai toujours pas trouvé la source du problème. Je vais ouvrir une autre question pour cela ( qui utilise mes threads de travail? SQL Server 2014 - HADR ).