Einfache Frage

Wie wird der SQL Server Quantum (4 ms) mit dem Server OS Quantum synchronisiert (normalerweise: 187,5 ms)?

Einfache Frage erklärt

Nachdem 184 ms OS-Quantum verwendet wurden (was 46 vollständigen SQL-Quantums entspricht), hat das OS-Quantum 3,5 ms Zeit, bevor es den Zeitplan an einen anderen Prozess übergeben muss. Das SQL-Betriebssystem startet ein Quantum (4 ms) und nach 3,5 ms hat das OS-Quantum entschieden, den aktuellen SQL-Betriebssystem-Thread zu stoppen, der noch 0,5 ms hat, bevor er den Zeitplan liefern würde. Was passiert jetzt?

---

Deep Dive auf OS Quantum

In den nächsten Abschnitten schreibe ich auf, was ich bisher in Bezug auf das OS-Quantum gefunden habe und wie die Dauer eines Quantums berechnet werden kann. Die Dauer eines OS "Quantums" basiert auf "Ticks" und die Dauer des "Ticks" selbst basiert auf dem "Taktintervall", das normalerweise 15,625000 ms beträgt. Aber lassen Sie mich etwas näher darauf eingehen ...

Tick

Im Blogartikel Know Thy Tick erklärt der Autor Jim die Grundlagen der Taktintervalle (auch "Ticks" genannt) und wofür sie gedacht sind.

Wenn ich so etwas wie "Das Taktintervall ... für die meisten x86-Multiprozessoren beträgt etwa 15 Millisekunden" lese, muss ich den Wert meines Takt- oder "Tick" -Intervalls bestimmen. Glücklicherweise enthält das Buch, in dem ich dieses Zitat gelesen habe, die vierte Ausgabe von Windows Internals eine Referenz, die mir bei meinem Leiden hilft. ... Der Autor, Mark Russinovich, des vorgenannten Buches hat das Dienstprogramm ClockRes freundlicherweise auf seiner Website zur Verfügung gestellt. Mit diesem Dienstprogramm konnte ich feststellen, dass das Taktintervall auf meinem x86-Multiprozessor-PC 15.625000 ms beträgt. Interessant, aber mein neugieriger Verstand möchte mehr wissen.

Quantum

Der Autor des Artikels erklärt weiter in seinem zweiten Artikel Das...

Der eigentliche Grund, warum das Tick-Intervall wichtig ist, ist natürlich, dass es die Thread-Planung beeinflusst . Der Windows-Scheduler gibt jedem Thread eine bestimmte Ausführungszeit, bevor eine andere Task mit derselben Priorität ausgeführt werden kann. Das Quantum, das der Scheduler einem Thread zuweist, ist ein Vielfaches des Tick-Intervalls . Der bestimmte Quantenwert, der für einen bestimmten Thread ausgewählt wurde, ist ein Stück weiter entfernt als ich mit diesem Artikel möchte.

Ok, ich weiß also, was ein Quant ist, aber nicht, wie lange ein Quant laufen wird.

Lassen Sie uns zunächst den Standardquantenwert für einen Vordergrund-Thread in XPe untersuchen. In diesem Fall weist der Windows-Scheduler ein Quantum von 18 oder 6 Tick-Intervallen zu. (Ja, um Quanten- in Tick-Intervalle umzuwandeln, muss man durch 3 teilen. ..., aber der Grund für das Vielfache ist, dem Scheduler die Möglichkeit zu geben, einen Thread für die Ausführung einer Operation zu "laden", die ihn zum Anhalten bringt.)

Wir wissen jetzt, dass ein Taktintervall (Tick) ungefähr 15,625000 ms betragen sollte, und auf einem Windows-Desktop-Betriebssystem, bei dem das Standardquantum 18 ist, führt dies zu 6 Ticks oder 93,750000 ms (18/3 * 15,625000 ms).

Unter einem Windows Server-Betriebssystem unterscheidet sich das Standardquantum. Die Einstellung "Prozessorplanung" ist auf "Hintergrunddienste" festgelegt.

^{Diese Einstellung finden Sie unter "Systemeinstellungen | Erweitert (Registerkarte) | Leistung (Abschnitt) | Einstellungen ...". Daraufhin wird "Leistungsoptionen | Erweitert (Registerkarte) | Prozessorplanung" geöffnet.}

Die Standardquanteneinstellungen sind dann 36 (Hintergrund) bis 36 (Vordergrund). Das Quantum ist größer und damit länger. Dies ist doppelt so viel wie die 93,750000 ms der 18 (6 Tick) -Quanten-Vordergrundeinstellung unter einem Windows-Desktop-Betriebssystem, das auf einem für Hintergrunddienste eingerichteten Server-Betriebssystem etwa 187,500000 ms beträgt.

Beobachtung / Erklärung

Wenn Sie auf einem Server oder einem Desktop die Einstellung von "Hintergrunddienste" in "Anwendungen" ändern, wird der Schlüssel HKLM \ SYSTEM \ CurrentControlSet \ Control \ PriorityControl \ Win32PrioritySeparation in der Registrierung von 0x18 in 0x02 geändert. Was ist der Standardquantenwert für 0x02? Dies kann in einem Kommentar gefunden werden:

Der Wert 0x02 impliziert, dass die Felder "Short vs. Long" und "Variable vs. Fixed" der Standard für das Betriebssystem sind.

Die Standardeinstellung für diese Felder für XPe und XP Pro lautet: Kurz und variabel. Dies entspricht dem Festlegen der folgenden zusätzlichen Bits: 0x24.

Wenn Sie diesen Wert mit 0x02 ODER-verknüpfen, erhalten Sie 0x26, die Sie in der Tabelle im Artikel finden.

^{Referenz: Kommentar zu "Master Your Quantum" (MSDN Blogs)}

Die Tabelle mit den Quanteneinstellungen aus demselben Artikel:

Win32PrioritySeparation   Foreground   Background
0x28, 0x29, 0x2A                  18           18
0x18, 0x19, 0x1A                  36           36
0x24                               6            6
0x25, 0x14                        12            6
0x26                              18            6
0x15                              24            6
0x16                              36            6

Kurze Zusammenfassung von OS Quantum

Anhand der obigen Informationen und Artikelzitate wissen wir, dass ein Quantum keine feste Größe ist, sondern von einer Betriebssystemeinstellung in den Systemeigenschaften abgeleitet wurde. Ein Quantum variiert abhängig von der Win32PrioritySeparationEinstellung in der Registrierung, die normalerweise einer der Einstellungen in den "Systemeigenschaften" (entweder "Hintergrunddienste" oder "Anwendungen") entspricht.

Ein Quantum auf OS-Ebene ist

• für die Einstellung "Anwendungen"
  • 18 (das sind 6 Ticks) für Vordergrundanwendungen (93,75 ms)
  • 6 (das sind 2 Ticks) für Hintergrundanwendungen (31,25 ms)
• für die Einstellung "Hintergrunddienste"
  • 36 (das sind 18 Ticks) für Vordergrundanwendungen (187,5 ms)
  • 36 (das sind 18 Ticks) für Hintergrundanwendungen (187,5 ms)

Jetzt wissen wir also, dass ein Betriebssystemquant auf einem Windows Server-Setup, das für Background Services optimiert werden soll, ...

36 / 3 * 15.625000 ms = 187.5 ms

---

SQL OS Quantum

Dieser Abschnitt listet auf, was ich in SQL OS Quantum gefunden habe ...

SOS_SCHEDULER_YIELD Wartetyp

Aus der Beschreibung von Paul Randall zum Wartetyp SOS_SCHEDULER_YIELD:

Bei diesem Wartetyp konnte ein Thread sein gesamtes Thread-Quantum ausführen (4 Millisekunden in allen Versionen von SQL Server, unveränderlich ), und so gab der Scheduler freiwillig nach und bewegte sich in seinem Scheduler an den unteren Rand der ausführbaren Warteschlange.

^{Referenz: SOS_SCHEDULER_YIELD (SQLSkills.com-Wartetypen)}

Scheduler in SQL Server-DMVs

In einer Erläuterung zu SQL Server-DMVs für die DMV sys.dm_os_schedulers.

[...] Windows verwendet einen präemptiven Planungsmechanismus und weist jedem Thread ein Quantum an CPU-Zeit zu. Wenn ein Thread sein Quantum verbraucht, wird es an eine Warteschlange gesendet und anderen Threads wird die Ausführung gewährt.

Im Gegensatz dazu verwendet SQL Server einen kooperativen Planungsmechanismus, wenn Threads freiwillig ihre Zeitmenge liefern können (Sie können dieses Verhalten sehen, wenn Sie einen SOS_SCHEDULER_YIELD-Wartetyp haben). Auf diese Weise kann SQL Server die CPU-Auslastung optimieren, da ein Thread, der zur Ausführung signalisiert wird, aber noch nicht zur Ausführung bereit ist, seine Zeitmenge zugunsten anderer Threads aufbringen kann .

^{Referenz: Grundlegendes zu SQL Server-Schedulern, -Arbeitern und -Tasks (MSSQLTips.com)}

Ermitteln Sie den SQL Server-CPU-Druck

Dies ist ein sehr kleiner Abschnitt eines Artikels über den CPU-Druck in SQL Server.

Tritt ein, wenn eine Aufgabe den Scheduler freiwillig für die Ausführung anderer Aufgaben angibt. Während dieses Wartens wartet die Task darauf, dass ihr Quantum erneuert wird .

^{Referenz: Ermitteln des SQL Server-CPU- Drucks (MSSQLTips.com)}

sys.dm_os_schedulers (Microsoft Docs)

Ich denke, das folgende Zitat ist der wichtigste Ausschnitt von Informationen zu SQL OS Quantum, den ich finden konnte:

quantum_length_us bigint  Identified for informational purposes only. 
                          Not supported. Future compatibility is not guaranteed. 
                          Exposes the scheduler quantum used by SQLOS.

^{Referenz: sys.dm_os_schedulers (Transact-SQL) (Microsoft | Docs)}

---

Mein Rätsel

Das Server-Betriebssystem Quantum regelt, wie viel Zeit dem SQL Server-Dienst zur Ausführung von "Aufgaben" gewährt wird. Das SQL Server-Betriebssystem Quantum ist als 4 ms definiert. Wenn ich die 187,5 ms durch 4 ms teile, verbleiben mir 3,5 ms.

Und wir haben noch nicht einmal mit der Diskussion begonnen, wann das Taktintervall auf einen anderen Wert als den Standardwert von 15,625000 ms eingestellt ist.

Einfache Frage

Wie wird der SQL Server Quantum (4 ms) mit dem Server OS Quantum synchronisiert (normalerweise: 187,5 ms)?

Einfache Frage erklärt

Nachdem 184 ms OS-Quantum verwendet wurden (was 46 vollständigen SQL-Quantums entspricht), hat das OS-Quantum 3,5 ms Zeit, bevor es den Zeitplan an einen anderen Prozess übergeben muss. Das SQL-Betriebssystem startet ein Quantum (4 ms) und nach 3,5 ms hat das OS-Quantum entschieden, den aktuellen SQL-Betriebssystem-Thread zu stoppen, der noch 0,5 ms hat, bevor er den Zeitplan liefern würde. Was passiert jetzt?

Auch wenn der Scheduler keine Präventivfunktion hat, folgt der SQL Server-Scheduler dennoch einem Quantenkonzept. Wenn SQL Server-Tasks vom Betriebssystem gezwungen werden, die CPU freizugeben, können sie in regelmäßigen Abständen eine Warteschlange anfordern, und wenn sie die intern festgelegte Anzahl von 4 Millisekunden überschritten haben und sich nicht in der Mitte eines Vorgangs befinden das kann nicht gestoppt werden, sie geben freiwillig die CPU frei.

- " Microsoft SQL Server 2012 Internals ", Kalen Delaney et. al. pp38

-Kapitel 2 "Das SQLOS" Jonathan Kehayias

Die Vorstellung eines "Quantums" in SQL Server ist also eher eine "Richtlinie" für Programmieraufgaben. Wenn Sie z. B. eine Aufgabe schreiben, die einen Tabellenscan ausführt, und wenn Sie eine Weile keine Seiten-, E / A-Verriegelungs- oder Sperrvorgänge ausführen, sollten Sie anhalten, was Sie tun, und danach fragen wieder in die ausführbare Warteschlange stellen, falls noch andere Aufgaben anstehen.

Aber es liegt an dem Task-Programmierer, dies zu implementieren, und es sind möglicherweise nicht genau 4 ms für jede Art von Task. Beispielsweise könnte die Tabellenscanaufgabe eine einfache Heuristik verwenden, die auf der Anzahl der Seiten basiert, die gescannt wurden, um die Streckgrenzen zu implementieren.

So

Das SQL-Betriebssystem startet ein Quantum (4 ms) und nach 3,5 ms hat das OS-Quantum entschieden, den aktuellen SQL-Betriebssystem-Thread zu stoppen, der noch 0,5 ms hat, bevor er den Zeitplan liefern würde. Was passiert jetzt?

Wenn der SQL Server-Thread von Windows vorab ausgeführt wird, wird er angehalten und beim nächsten geplanten Thread auf einer CPU dort fortgesetzt, wo er aufgehört hat. Vermutlich wird es weiterhin den Rest seines 4-ms-Quants verbrauchen, da es keinen Unterschied erkennen würde. Aber auch hier ist das Ertragsverhalten ein Implementierungsdetail der Aufgabe und kein Verhalten von SQLOS, sodass sich verschiedene Aufgaben hier möglicherweise unterschiedlich verhalten.

_{Antworten Sie auf Beiträge, die ursprünglich als Kommentare hinterlassen wurden}

Wie wird der SQL Server Quantum (4 ms) mit dem Server OS Quantum synchronisiert (normalerweise: 187,5 ms)?

Dies ist nicht der Fall und SQL Server verwendet keine präemptive Zeitplanung. Von Arbeitselementen wird erwartet, dass sie Ertragspunkte erreichen. Wenn dies nicht der Fall ist, erhalten Sie beispielsweise NONYIELDINGPlaner. Es gibt keine Parität. SQL Server verteilt die Zeit nicht. Es macht bestimmte Threads für Windows attraktiv, um sie zu planen, und Windows plant sie. Quantum ist nur eine Nomenklatur für eine Weile. Das ist es. SQL Server ist nicht präventiv, es liegt in der Verantwortung dessen, was ausgeführt wird, sich im gesamten Code auszugeben. - Sean Gallardy

Wenn das OS-Quantum abläuft, wird der Thread zwangsweise entkalkt. Dies ist für SQL Server transparent. SQLOS kann dies nicht erkennen. Dafür gibt es keine Win32-API. Die Zeitplanung ist für Threads im Benutzermodus transparent. Der Windows-Scheduler weiß oder kümmert sich nicht darum, welche Benutzermodus-Threads ausführen. Windows erkennt nur ausführbare Threads und lässt sie bis zum Ende ihres Betriebssystemquants oder bis zum Blockieren laufen. - usr

In Wie man mit übermäßigen SOS_SCHEDULER_YIELD-Wartetypwerten in SQL Server von Nikola Dimitrijevic umgeht , bedeutet der Begriff "Quantum" im Wesentlichen "die Zeit, die eine Aufgabe tatsächlich einem Worker zuweist ", aber das ist nicht der gleiche Sinn wie ein Windows-Quantum. Dies ist eine Zeitspanne, nach der das Betriebssystem einen Thread von einer CPU entfernt. Sie sind nur unterschiedliche Konzepte. Wenn das Betriebssystem das Beenden der Ausführung eines Threads erzwingt, weil das OS-Quantum erreicht wurde, erfolgt eine Kontextumschaltung. Der Thread von SQL Server wird wie jedes andere Programm angehalten. - David Browne - Microsoft und George.Palacios .

---

Auszüge aus der Dokumentation: Im SQL Server 2000 User Mode Scheduler (geschrieben für SQL Server 2000, aber immer noch relevant):

Präventives vs. kooperatives Tasking

Im Gegensatz dazu ist UMS auf Threads angewiesen, um freiwillig nachzugeben. UMS geht so vor, dass der Windows-Kernel nicht mehr als unbedingt erforderlich eingebunden wird. In einem System, in dem man sich darauf verlassen kann, dass Worker-Threads zum richtigen Zeitpunkt ihre Ergebnisse liefern, ist ein kooperativer Scheduler möglicherweise effizienter als ein präventiver, da der Scheduling-Prozess auf die spezifischen Anforderungen der Anwendung zugeschnitten werden kann. Wie bereits erwähnt, kennt UMS die Planungsanforderungen von SQL Server besser, als vom Betriebssystem erwartet werden kann.

Wie UMS die Terminplanung übernimmt

Wenn UMS die Scheduling-Anforderungen von SQL Server erfüllen soll, anstatt dies von Windows zuzulassen, muss UMS auf irgendeine Weise verhindern, dass das Betriebssystem bei jedem anderen Prozess die gleichen Aktionen ausführt: Planen Sie Threads auf den oder den Prozessoren des Systems nach eigenem Ermessen. Wie macht man das in einem präventiven Betriebssystem? UMS führt dies durch einige clevere Tricks mit Windows-Ereignisobjekten durch. Jedem Thread unter UMS ist ein Ereignisobjekt zugeordnet. Zum Zwecke der Zeitplanung ignoriert Windows Threads, die es als nicht realisierbar erachtet - Threads, die nicht ausgeführt werden können, weil sie sich in einem unendlichen Wartezustand befinden. Sie nennen UMS setzt Threads Schlaf man das weiß, dass es nicht will , durch eingeplant werden, die WaitForSingleObject auf ihren entsprechenden Ereignisobjekt und vorbei INFINITE für den Timeout - Wert.

Um zu verhindern, dass Windows mehrere Threads auf demselben Prozessor plant und dadurch den Overhead und die Kosten für Kontextwechsel verursacht, versucht UMS, nur einen Thread pro Prozessor funktionsfähig zu halten, dh nicht in einem unendlichen Wartezustand.