Was sind eigentlich Waits? Multitasking, wie macht’s SQL Server?

Was sind eigentlich Waits? Multitasking, wie macht’s SQL Server?

Kurz vorab:

Unser SQL Server Performance Tool SQL-Watch, wertet im Rahmen seiner automatischen Performanceanalyse, die im folgenden Artikel  erklärten Waits aus und bewertet diese. Hierbei werden  all die vielen wichtigen SQL Server Performanceindikatoren berücksichtigt.

Sie erhalten mit unserem Performance Tool SQL-Watch, einen umfangreichen Analysebericht, der neben all den wichtigen SQL Performanceparametern, natürlich auch Waits berücksichtigt und diese auswertet.

Die gezielte Auswertung  von Wait’s, sind unter anderem auch Bestandteil der umfangreichen Analyse unseres Performanceprodukts SQL Server Performance Pack.

Im folgenden Artikel möchten wir Ihnen dennoch erklären was Waits eigentlich sind und warum SQL Server Wait’s wichtig sind, um Performanceprobleme zu erkennen,zu analysieren und zu beheben.

Wenn Sie regelmäßig über interessante SQL Server News und Informationen informiert werden wollen, melden Sie sich einfach an unserem KOSTENLOSEN NEWSLETTER an.

Viele Spaß beim lesen.

Ihr sqlXpert Performanceteam

 

Was sind eigentlich Waits? Multitasking, wie macht’s SQL Server?

Ein Wait ist der Zustand in dem sich eine Task befindet wenn sie auf irgend etwas wartet.

SQL Server muss eine Menge an Aufgaben, auch Tasks genannt, möglichst schnell erledigen. Es handelt sich hierbei um Systemtasks, die die Funktionalität von SQL Server sichern. Außerdem, gibt es Tasks die die SQL Server Requests, also die SQL Anfragen und Befehle der Benutzer die mit SQL Server verbunden sind abarbeiten.

Damit eine Task abgearbeitet werden kann, benötigt sie Prozessorzeit, denn letztendlich ist der Prozessor die Kern-Hardwarekomponente die dies ermöglicht.

Auf Grund der Vielzahl von Tasks in SQL Server, ist es nicht möglich, dass der Prozessor eine Task abarbeitet und dieser so lange Prozessorzeit gibt, bis diese irgendwann einmal fertig ist. Egal wie lange diese läuft. Würde nämlich eine Task 1 Stunde Zeit benötigen, würden die nach diesem Prinzip  folgenden anderen Tasks, so lange warten müssen, bis sie an die Reihe kämen.

Auf diese Art und Weise wäre es nicht möglich, gleichzeitig an einer Datenbank zu arbeiten. Es wird also ein Mechanismus benötigt, der es ermöglicht alle Tasks parallel auszuführen.

Um alle anfallenden Tasks abzuarbeiten und jeder Task die Möglichkeit zu geben, abgearbeitet zu werden, wird jede Task in kurzen Abständen aufgrufen und erhält einen kleinen Moment Prozessorzeit.

Bei SQL Server ist dieser Zeitraum genau 4 Millisekunden lang und wird als Quantum bezeichnet. Der Status einer gerade aktiven Task (Task hat Prozessorzeit) wir in diesem Moment als running bezeichnet.

Wenn es die Task in diesem Zeitraum nicht schafft ihre Aufgabe zu erledigen, wird sie abgebrochen und in einer internen Liste Namens Runnable List  am unteren Ende eingefügt, sowie als nicht fertig mit dem Status (runnable) markiert.

Ebenfalls werden neue Tasks, die abgearbeitet werden müssen, am unteren Ende der Runnable List direkt mit dem Status runnable eingefügt.

Die Runnable List arbeitet nach dem FIFO (First in First out) Prinzip. Task’s die zuerst eingeordnet werden, erhalten demnach zuerst erneute Prozessorzeit, indem sie innerhalb der Liste durch neue hinzugefügte Task‘s nach oben rutschen.  Da in diesem Zustand die Task immer noch auf Prozessorzeit wartet spricht man von einem Signal Wait.

Task‘s die während ihrer aktiven Abarbeitung (also im Status running)  auf eine Ressource zugreifen wollen, die gerade von einem anderen Prozess blockiert wurde, werden ebenfalls sofort abgebrochen und in eine weitere Liste der sogenannten Waiter List mit dem Status suspended eingefügt. Hier spricht man von einem Resource Wait.

Dies ist zum Beispiel der Fall, wenn eine Task einen Datensatz in einer Tabelle verändern möchte, dies aber nicht darf, da eine andere Task diese Datenzeile ebenfalls ändern möchte und diese für diesen Vorgang  gesperrt hat.

Wie kommt eine Task aus der Waiter List wieder heraus?

Wenn eine Task, die eine bestimmte Ressource gesperrt hat und diese wieder freigibt, da die Sperre nicht mehr benötigt wird, checkt sie die Waiter List nach Tasks die auf diese Ressource gewartet haben und die genau aus diesem Grund ja in der Waiter List stehen.

Diese Tasks, werden jetzt aus der Waiter List entfernt und mit dem Status runnable in die Runnable List wie zuvor beschrieben (FIFO) eingereiht. Der Versuch der Abarbeitung beginnt erneut wenn diese an die Reihe kommt.

Das ist der Kreislauf nach dessen Muster Tasks in SQL Server abgearbeitet werden.

Man bezeichnet dies auch als Non-Preemptive Scheduling und meint damit das jeder Task unabhängig ob sie fertig ist oder nicht, nur ein kleines Quantum Prozessorzeit eingeräumt wird. Schafft sie es nicht in diesem Zeitraum ihre Aufgabe zu erledigen , wird sie abgebrochen. Schafft sie es,  umso besser.

Es gibt auch noch das sogenannte Preemptive Scheduling. Das meint, das jeder Task eine gewisse Priorität, je nachdem wie wichtig sie ist eingeräumt wird. Anhand dieser Priorität wird der Task mehr oder weniger Prozessorzeit eingeräumt.

Windows selbst arbeitet mit dem Preemptiven Scheduling. SQL Server allerdings NICHT!

Egal ob Non-Preemptive Scheduling  oder Preemptives Scheduling. Dadurch das jede Task in kurzen Zyklen Prozesssorzeit erhält entsteht die Illusion das alle Tasks gleichzeitig abgearbeitet werden.

 

Wait Typen

Für jede Task die nicht läuft, zeichnet das SQL Server OS (Operating System) Informationen über die Länge der Wartezeit und  die eigentliche Ursache auf. Das ist der eigentliche Wait der gemessen werden kann.

Wartegründe für eine Task kann es viele geben. Diese unterschiedlichen Arten werden klassifiziert und man nennt diese dann Wait Types (Wartetypen). Ein Wait Typ, gibt klar Auskunft warum bzw. worauf eine Task wartet.

Damit die einzelnen Waits unterschieden werden können, gibt es unterschiedliche Bezeichnungen für diese Wait Typen.

LCK_****

Diese Informationen werden für gerade aktuelle, jedoch nicht laufende Tasks aufgezeichnet und es werden auch Gesamtinformationen über aktuell relevante Wait Typen aufsummiert.

Diese aufgezeichneten Gesamtinformationen, bezeichnet man als wait statistics (Wartestatistiken) oder wait stats. Damit wird ersichtlich, welche Wait Typen wieviel Zeit in Anspruch genommen haben und wie häufig diese aufgetreten sind.

Um diese wartenden Tasks bzw. die Informationen dazu einzusehen, gibt es mehrere Dynamic Management Views (DMV‘s).

Name der DMV Beschreibung
sys.dm_os_wait_stats Alle relevanten Waittypen mit der bisherigen aufsummierten Häufigkeit (waiting_tasks_count), Dauer (wait_time_ms) der Maximalen Wartezeit (max_wait_time_ms) und der summierten Signal Waittime (signal_ wait_time_ms). Also anders gesagt, finden Sie hier die Werte wie oft ein Waittype vorgekommen ist und wie groß die summierte Gesamtzeit ist, die für diesen Waittype angefallen ist. Ebenso wird die längste Wartezeit und die summierte Wartezeit in der Runnable Liste angezeigt.
sys.dm_os_waiting_tasks Zeigt die Waiter List in Echtzeit an. Hier finden Sie alle Tasks, die gerade auf eine Ressource warten. Auch hier finden Sie den Wait Type (wait_type), Die aktuelle Wartedauer (wait_duration_ms) und die Session ID (session_id) zu der der Wait gehört.
sys.dm_exec_session_wait_stats Zeigt Ihnen die gleichen Informationen wie in sys.dm_os_wait_stats allerdings nur für gerade Active Sessions. Diese Management View wurde erst mit der Version SQL Server 2016 eingeführt.

 

Optimierung durch Beobachtung von Waits?

Die Frage die man sich nun stellt, wie kann ich denn jetzt SQL Server auf Basis von Waits optimieren?

Zunächst muss auf jeden Fall erst einmal gesagt werden, das Waits etwas völlig normales sind. Wenn man Waits beobachtet und sich die unterschiedlichsten Waits Typen ansieht, gehört dies grundsätzlich erst einmal zum normalen Arbeitsablauf von SQL Server.

Problematisch wird das Ganze erst, wenn Waits des gleichen Typ’s sehr häufig vorkommen und übermäßig viel Zeit in Anspruch nehmen. Zum Beispiel kann es auf ein Problem hindeuten, wenn sehr viele Waits eines bestimmten Typs auftreten und in der Summe auch viel Zeit benötigen.

Dies deutet daraufhin, das Tasks auf bestimmte Vorgänge warten müssen. Zum Beispiel langwieriges schreiben in das Logfile oder warten auf Sperren die durch andere Datenänderungen von anderen Sessions gesetzt wurden.

Genau aus diesen genannten Gründen ist es wichtig im Rahmen einer Performanceanalyse auch Wait’s auszuwerten um die Schwachstellen in Ihrem SQL Server System zu erkennen.

Autor: Michael R. Friebel