Utilisation élevée du thread de travail HADR

Pourquoi le nombre de threads de travail d'un groupe de disponibilité dans un pool HADR augmenterait-il bien au-delà de l'utilisation minimale de « généralement, il y a 3 à 10 threads partagés » par réplique?

Dans un cas, nous avons observé l'utilisation de plus de 300 threads avec 3 groupes de disponibilité et 10 bases de données au total. SQL Server 2014 SP1.

Nos pistes sont la sauvegarde sur la réplique secondaire, une activité élevée sur la réplique principale, des rapports sur la réplique secondaire.

Les AG sont dans un centre de données sur VMware. 16 ordonnanceurs au total, les threads de travail habituels sont inférieurs à 200. max_dop sur le serveur est 2.

3 AG, 10 DB, 4 répliques chacun - primaire, 2 en lecture seule, 1 non lisible.
1 secondaire est synchronisé, 2 asynchrones
16 vcores sur 32 cœurs physiques sur un grand cluster multi-hôtes.
Pas de surprovision.
D'autres petits cœurs de machines virtuelles 4-8 sont colocalisés, mais ils n'appuient pas sur le processeur

Nous avons observé une pointe dans les fils de travail entraînant un déni de service. L'attribution de threads de travail à AG est notre hypothèse, car seuls ces threads de travail peuvent franchir la limite.

Les liens ci-dessous du blog SQL Server Premier Field Engineer lus dans leur contexte ne me donnent pas une réponse complète:

— Alexander Tarasul
source

Pouvez-vous publier des exemples de captures d'écran de ce que vous voyez? Quelque chose semble ici, comme si vous interrogiez les threads de travail en général, par opposition à ceux d'AG en particulier. (Et d'autres threads de travail peuvent également franchir la limite, pas seulement ceux d'AG.)

— Brent Ozar

Je chasse un problème similaire. Je suis presque sûr d'avoir résolu le problème de MaxDop. J'utilise des scripts Ola Hallengreens pour IndexMaintenance, et le paramètre MaxDOP a été défini sur NULL. Le point est, pourriez-vous avoir des requêtes entrant, qui remplacent votre MaxDOP 2?

— Kasper Brandenburg

Avez-vous trouvé une solution à cela?

— trusha

-1

Étant donné que votre contrôleur de domaine est sur VM, je soupçonne que vous rencontrez des performances de disque médiocres. Des performances de disque médiocres peuvent entraîner des temps d'écriture de journal plus lents sur le secondaire, ce qui peut entraîner un accusé de réception plus lent vers le réplica principal à partir du réplica secondaire (épuisement des threads de travail).

La latence du disque sur le réplica secondaire peut entraîner une augmentation du processus HADR Sync Commit, ce qui entraîne le principal à maintenir les threads ouverts en attendant que le secondaire reconnaisse la transaction.

Veuillez consulter le journal des erreurs pour les planificateurs bloqués et collecter des métriques d'E / S de PerfMon pour voir la latence du disque et la longueur de la file d'attente de disque.

— Rodrigo Nascentes
source