Discussion :

[agdid04]

Bonsoir,

J'ai ce message:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

Nombre maximum de threads de travail est 0

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

MERCI.

A+

[mikedavem]

Hello,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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;

++

[agdid04]

Bonjour et Merci Mikedavem,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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 +

[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+

[mikedavem]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

++

[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+

[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+

[SQLpro]

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 +