Question Pool Alwayson Group

Version imprimable

Bonsoir,

J'ai ce message:
Code:

1 2 3 Le pool de threads pour la fonctionnalité Groupes de disponibilité AlwaysOn n'a pas pu démarrer un nouveau thread de travail, car le nombre de threads de travail disponibles est insuffisant. Cela peut dégrader les performances de la fonctionnalité Groupes de disponibilité
Comment voir le nombre de threads ? L'augmenter ? Si oui avec redémarrage de l'instance ou pas ?

J'ai bien:

Code:

Nombre maximum de threads de travail est 0

Dans Propriétés (Instance) puis Processeurs => donc illimité

MERCI.

A+

Hello,

Est-ce que tu peux dans un premier temps poster le résultat des requêtes suivantes?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
SELECT @@VERSION;
 
SELECT 
	cpu_count, hyperthread_ratio
FROM sys.dm_os_sys_info;
 
SELECT COUNT(*) as nb_schedulers
FROM sys.dm_os_schedulers
WHERE status = 'VISIBLE ONLINE'
GO
 
SELECT name, value, value_in_use
FROM sys.configurations
WHERE name LIKE 'affinity%'
 
SELECT COUNT(*)
FROM sys.databases
WHERE database_id > 4;

Bonjour et Merci Mikedavem,

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
SELECT @@VERSION;
 
Microsoft SQL Server 2012 (SP4) (KB4018073) - 11.0.7001.0 (X64) 
Enterprise Edition (64-bit) 
 
SELECT 	cpu_count, hyperthread_ratio
FROM sys.dm_os_sys_info;
cpu_count	hyperthread_ratio
16	16
 
 
SELECT COUNT(*) as nb_schedulers
FROM sys.dm_os_schedulers
WHERE status = 'VISIBLE ONLINE'
GO
nb_schedulers
16
 
SELECT name, value, value_in_use
FROM sys.configurations
WHERE name LIKE 'affinity%'
name	value	value_in_use
affinity mask	0	0
affinity64 mask	0	0
affinity I/O mask	0	0
affinity64 I/O mask	0	0
 
SELECT COUNT(*)
FROM sys.databases
WHERE database_id > 4;
(Aucun nom de colonne)
441

MERCI.

01/08/2019, 10h24
SQLpro

est- ce que chacune de vos bases est dans un groupe de disponibilité spécifique ? et en quel mode (synchrone ou asynchrone) ?

Parce que de mémoire le mode synchrone consomme 3 threads par AG, soit 441 * 3 = 1 323 threads…. Soit plus que 704, limite dans le cas de 16 cœurs
(la formule étant : 512 = (nbCoeurs - 4) * 16...

Il faudrait donc peut être augmenter le nombre de max worker threads….

A +
01/08/2019, 12h23
agdid04

Bonjour et Merci SQLPro,

Dans mon groupe de disponibilité, il y a 331 bases en mode synchrone.
Quand est ce qu'un thread est activé ? car depuis plus de 3 ans c'est la 1ère fois ce message est remonté.
Est-ce qu'il y a un compte threads actifs qq part ...?
Comment augmenter le nombre de max worker threads ?

Je peux mettre Nombre maximum de threads de travail = 1500 ? est-ce qu'il faut redémarrer mon instance dans ce cas ?

Il y avait ~ 350 sessions SQL au moment de la remontée de message ....

Merci.

A+

Les groupes de disponibilités fonctionnent par pool de worker thread. Si une base de données est active alors comme stipulé par SQLPro tu auras de base 3 threads consommés. Ce nombre augmente si tu utilises les secondaires pour effectuer les backups ou que tu utilises filestream par exemple. En revanche pour une base de données qui n'est pas/plus active (idle > ~15s) les threads sont restitués au pool.

Pour 331 bases de données dans le pire de cas ton pool devrait avoir 331 * 3 = 993 threads alors que tu n'as que 16 schedulers de dispo soit 704 - 40 = 664 threads max disponible pour ton pool de threads AG si mon calcul est juste.

Possible que ton activité ait évolué et sollicite plus tes bases de données maintenant ... Pour cela il faudrait avoir un historique des worker threads consommés dans ce fameux pool. Tu peux le monitorer avec une session d'événement étendue. Par exemple:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 create event session HadrThreadPoolWorkerStart on server add event sqlserver.hadr_thread_pool_worker_start add target package0.event_file ( set filename = N'<path>\HadrThreadPoolWorkerStart.xel' ) with ( max_memory = 4096 KB, event_retention_mode = allow_single_event_loss, max_dispatch_latency = 30 seconds, max_event_size = 0 KB, memory_partition_mode = none, track_causality = off, startup_state = on ); go
Tu peux augmenter le nombre de threads mais il faut déjà s'assurer que ta consommation CPU n'est pas proche du max possible et ou cela ne te provoque pas des effets de bords au niveau des attentes. Un redesign de ton architecture est peut être nécessaire en fonction de ce que te dira la trace d'événement étendue.

++

04/08/2019, 12h53
agdid04

Merci bcp.

encore une question: est ce qu'il y a une relation entre les sessions utilisateurs (sys.dm_exec_sessions) et worker threads ?

Dans certains cas le suppression de certaines sessions SQL relance la prod....

MERCI.

A+
05/08/2019, 07h32
mikedavem

Il y a forcément une relation puisqu’une session va initier un travail qui fera appel à N worker threads pour effectuer les tâches nécessaires à l’exécution d’une requête par exemple et au travail de synchro pour les bases.

En général l’augmentation d’utilisation de worker threads sur les groupes de disponibilités est liée à une activité sur le serveur qui augmente et un nombre de bases qui devient important.

A+
06/08/2019, 09h20
SQLpro
Citation:

Envoyé par agdid04

Bonjour et Merci SQLPro,

Dans mon groupe de disponibilité, il y a 331 bases en mode synchrone.

...

La question centrale est :
- pourquoi autant de bases de données ? N'y a t-il pas une mauvaise architecture ?
Et la question corollaire est :
- avez-vous mis les ressources nécessaire au niveau hardware pour absorber une telle quantité de bases de données ?
Sachant que plus vous avez de bases, plus il y a de ressources diverses consommées !

A +