Plötzlich wurde der SQL Server mit ausstehender Taskanzahl neu gestartet

Question

Wir versuchen das Problem zu verstehen, bei dem SQL Server plötzlich von selbst neu gestartet wurde.

Es ist ein SQL Server 2012 SP4-GDR, der mit 40 CPUs aktiviertem HT angewendet wird, also insgesamt 80 logische Prozessoren.

MAXDOP = 8, CTOP 5

Aus Fehlerprotokollen haben wir gefunden

/ ********************** /

BEGIN Stack Dump

Non-Yielding Scheduler / ********************** /

Fehlermeldungen nur zum Zeitpunkt des Neustarts von SQL. Außerdem wurde kein Mini-Dump wie aktiviert erstellt.

Ja, wir haben zu diesem Zeitpunkt einige Abfragen. Die drei wichtigsten Wartezeiten waren:

1.TranLogIO
2.CXPACKET
3.PAGELATCH SH

Wir haben jedoch auch bemerkt, dass das Warten SOS WORKERals vom Systemzustand XE gesammelt bezeichnet wird, was meiner Meinung nach nichts anderes ist als THREADPOOL. Daher ging ich weiter und analysierte die Details der Abfrageverarbeitung aus diesem Systemzustand und stellte fest, dass zum Zeitpunkt nicht nachgebender Scheduler-Fehler unten protokolliert wurde

Um 19:46 maxworkers- 2944 workers created789 oldest pending taskwait time0 ausstehende Aufgabe 4

Um 19:51 maxworkers- 2944 workers created982 oldest pending taskwait time256987 anstehende Aufgabe 165

Um 19:51 Uhr wurde ein Neustart durchgeführt.

Die Frage ist, warum es eine Threadpool-Wartezeit geben würde, wenn nach der obigen Berechnung noch fast 2000 Mitarbeiter verfügbar wären. Warum zählen diese ausstehenden Aufgaben 165, wenn für Abfragen so viele Scheduler verfügbar sind, um die Anforderung für eine Reihe von Abfragen auszuführen und abzuschließen, die auf CXPACKETS warten?

Bearbeiten: Aktualisierung meiner Frage für einige Wartezeiten, die auch von XE aus gesehen wurden

SOS_MEMORY_TOPLEVELBLOCKALLOCATOR

Da ich oben Informationen lese, warte hier https://www.sqlskills.com/help/waits/sos_memory_toplevelblockallocator/

Basierend auf dem Blog gibt es einen Fix in SP3 CU, aber mit TF T8075: Ich bin derzeit auf dem neuesten SP4-DDR-Patch. Muss ich den TF noch anwenden, obwohl ich keine Meldungen wie Failed allocate pages: FAIL_PAGE_ALLOCATION 513im Fehlerprotokoll sehe

Ich bin mir nicht sicher, ob es hilft - ich sehe, dass der gesamte Serverspeicher ab und zu einen Gig verliert und dann mit dem Zielserverspeicher übereinstimmt, der = maximaler Serverspeicher (750 GB) ist.

Meistens insgesamt = Ziel = maximaler Serverspeicher. Die Tropfen sind nur ein Gig und nicht viel

Speicherinfo = Gesamt-RAM: 880 GB Maximaler Speicher: 750 GB Minimaler Serverspeicher: 130 GB Es handelt sich um einen Windows-Cluster mit 2 Knoten, und keine andere SQL-Instanz wird gemeinsam genutzt. Resource Governor ist nicht aktiviert

Vielen Dank

Answer 1

Ich würde damit beginnen, die beste Person zu sagen, um Dump bei MS-Typen oder Personen zu analysieren, die davon wissen. Ich würde nur versuchen, einige Grundlagen aus dem von Ihnen geposteten Protokoll herauszustellen

Um 19:46 Uhr haben maxworkers- 2944 Arbeiter 789 älteste ausstehende Taskwartezeit 0 0 ausstehende Aufgabe 4 erstellt. Um 19:51 maxworkers- 2944 Arbeiter haben 982 älteste ausstehende Taskwartezeit erstellt. 256987 ausstehende Task 165

Bitte sehen Sie das taskwait time 256987und pending task 165. Dies bedeutet, dass der Scheduler aufgehängt wurde und 165 Aufgaben darauf warteten, einen Scheduler zu erhalten und auszuführen. In diesem Fall konnte MS SQL Server dieses Szenario mit blockiertem Scheduler nicht verlassen und wartete eine Weile. Wieder entschied es jedoch, dass es am besten ist, sich selbst neu zu starten, um aus diesem Szenario mit blockiertem Scheduler herauszukommen, und startete daher neu. Aus dem Grund, warum es hängt, kann ich es nicht anhand der von Ihnen geposteten Informationen beurteilen.

Beachten Sie auch, dass einem Thread ein Scheduler zugewiesen ist und er auf diesem Scheduler ausgeführt werden sollte. Deshalb warteten so viele Threads auf diesen blockierten Scheduler.