Wer verwendet meine Worker-Threads? SQL Server 2014 - HADR

Wir hatten kürzlich ein Problem in unserer SQL Server 2014-HADR-Umgebung, in der einem der Server die Arbeitsthreads ausgegangen sind.

Wir haben die Nachricht erhalten:

Der Thread-Pool für AlwaysOn-Verfügbarkeitsgruppen konnte keinen neuen Worker-Thread starten, da nicht genügend Worker-Threads verfügbar sind.

Ich habe bereits eine andere Frage geöffnet, um eine Erklärung zu erhalten, die mir (ich dachte) helfen sollte, das Problem zu analysieren ( Ist es möglich zu sehen, welche SPID welchen Scheduler (Worker-Thread) verwendet? ). Obwohl ich jetzt die Abfrage habe, die Threads zu finden, die das System verwenden, verstehe ich nicht, warum diesem Server die Arbeitsthreads ausgegangen sind.

Unsere Umwelt ist wie folgt:

• 4 Windows Server 2012 R2
• SQL Server 2014 Enterprise
• 24 Prozessoren -> 832 Worker-Threads
• 256 GB RAM
• 12 Verfügbarkeitsgruppen (insgesamt)
• 642 Datenbanken (insgesamt)

Der Server mit dem Problem hatte also die folgende Konfiguration:

• 5 Verfügbarkeitsgruppen (3 primäre / 2 sekundäre)
• 325 Datenbanken (127 Primär / 198 Sekundär)
• MAXDOP = 8
• Cost Threshold for Parallelism = 50
• Der Energieplan ist auf "Hohe Leistung" eingestellt.

Um das Problem zu "beheben", haben wir eine Verfügbarkeitsgruppe manuell auf den sekundären Server übertragen. Die Konfiguration dieses Servers lautet jetzt:

• 5 Verfügbarkeitsgruppen (2 primäre / 3 sekundäre)
• 325 Datenbanken (77 primäre / 248 sekundäre)

Ich überwache die verfügbaren Threads mit dieser Anweisung:

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'

Normalerweise stehen auf dem Server etwa 250 bis 430 Arbeitsthreads zur Verfügung, aber als das Problem begann, waren keine Arbeiter mehr übrig.

Heute sind die verfügbaren Arbeitskräfte aus dem Nichts von 327 auf 50 gesunken, aber nur für eine Minute, und sind dann wieder auf rund 400 gestiegen.

Ich habe bereits die andere Frage gesehen ( HADR High Worker Thread-Nutzung ), aber sie hilft mir nicht.

Unser System lief über ein Jahr ohne Probleme stabil. Wir hatten kein Failover oder andere wesentliche Änderungen in der Verteilung der Datenbanken.

Wir verwenden "Synchronous Commit" zwischen den Replikaten. Nach meinem Verständnis ist keine Komprimierung erforderlich. Weitere Informationen finden Sie in der Dokumentation unter Komprimierung für Verfügbarkeitsgruppe optimieren.

Hat jemand eine Idee, was alle Worker-Threads verwendet?

BEARBEITEN: Auf dieser Seite finden Sie viele Informationen zu genau diesen Themen. Http://www.techdevops.com/Article.aspx?CID=24

_{Antwort des Community-Wikis :}

Sie haben eine große Anzahl von Datenbanken in Verfügbarkeitsgruppen. Dort werden Ihre Threads abgelegt. Die Komprimierungs-, Verschlüsselungs- und Transportkosten sind sehr hoch. Wenn Sie die Komprimierung deaktivieren, wird die Thread-Nutzung um etwa ein Drittel reduziert (abhängig von der Anzahl der Replikate).

Die Frage ist mit SQL Server 2014 gekennzeichnet, das standardmäßig die Komprimierung verwendet. SQL Server 2016 verwendet standardmäßig keine Komprimierung für die Synchronisierung.

Möglicherweise müssen Sie die Arbeitsthreads auf der Instanz erhöhen oder besser: Die aktivsten und inaktivsten auf mehreren Servern ausgleichen. Weitere Informationen finden Sie in den entsprechenden Fragen und Antworten zur AlwaysON-Verfügbarkeitsgruppenabfrage .

Möglicherweise handelt es sich auch um eine Anwendung, die Anforderungen nicht ordnungsgemäß schließen kann. Dies kann dazu führen, dass viele Schlafsitzungen herumliegen (die Arbeiter verbrauchen).

Die Anzahl der tatsächlich verwendeten Threads hängt davon ab, wie aktiv die Datenbanken sind. Sie könnten über 1.000 Datenbanken verfügen, und wenn die meisten in 95% der Fälle inaktiv sind, treten keine Probleme auf. Es scheint, dass Ihre Datenbanken häufiger aktiv geworden sind und mehr von Ihren Threads gefressen haben. Das ist das Lange und Kurze.