it-swarm.com.de

Windows OS Quantum vs. SQL OS Quantum

Einfache Frage

Wie wird das 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-Quanten entspricht), hat das OS-Quantum 3,5 ms Zeit, bevor es den Zeitplan einem anderen Prozess übergeben muss. Das SQL-Betriebssystem startet ein Quantum (4 ms) und nach 3,5 ms hat das Betriebssystem-Quantum beschlossen, den aktuellen SQL-OS-Thread zu stoppen, der noch 0,5 ms hat, bevor er den Zeitplan ergibt. Was passiert jetzt?


Deep Dive auf OS Quantum

In den nächsten Abschnitten werde ich aufschreiben, was ich bisher in Bezug auf das OS-Quantum gefunden habe und wie die Dauer eines Quantums berechnet werden kann. Die Dauer eines OS "Quanten" 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

In dem Blog-Artikel Know Thy Tick erklärt der Autor Jim die Grundlagen der Taktintervalle (auch bekannt als "Ticks") und wofür sie sind.

Wenn ich so etwas wie "Das Taktintervall ... für die meisten x86-Multiprozessoren beträgt ungefähr 15 Millisekunden" lese, muss ich den Wert meines Taktintervalls oder "Tick" -Intervalls bestimmen. Glücklicherweise bietet das Buch, in dem ich dieses Zitat in Windows Internals Fourth Edition gelesen habe, eine Referenz, um mir bei meinem Leiden zu helfen. ... Der Autor Mark Russinovich des oben genannten Buches hat das Dienstprogramm ClockRes freundlicherweise auf seiner Website verfügbar gemacht. 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 in seinem zweiten Artikel dass ...

Der wahre Grund, warum das Tick-Intervall wichtig ist, ist natürlich, dass es die Thread-Planung beeinflusst. Der Windows-Scheduler gibt jedem Thread eine „Zeitspanne“ für die Ausführung, bevor eine andere Aufgabe mit derselben Prioritätsstufe ausgeführt werden kann. Das Quantum, das der Scheduler einem Thread zuweist, ist ein Vielfaches des Tick-Intervalls . Der spezifische Quantenwert, der für einen bestimmten Thread ausgewählt wurde, liegt etwas darüber, wohin ich mit diesem Artikel gehen möchte.

Ok, ich weiß also, was ein Quanten ist, aber nicht, wie lange ein Quanten 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 Quantenintervalle in Tick-Intervalle umzuwandeln, muss man durch 3 teilen ... ... aber der Grund für das Vielfache besteht darin, dem Scheduler die Möglichkeit zu geben, einen Thread für die Ausführung einer Operation zu "laden", wodurch er angehalten wird.)

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

Unter einem Windows Server-Betriebssystem ist das Standardquantum unterschiedlich. Die Einstellung "Prozessorplanung" ist auf "Hintergrunddienste" eingestellt.

Diese Einstellung finden Sie unter "Systemeinstellungen | Erweitert (Registerkarte) | Leistung (Abschnitt) | Einstellungen ...", wodurch "Leistungsoptionen | Erweitert (Registerkarte) | Prozessorplanung" geöffnet wird.

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) Quantenvordergrund-Einstellung auf einem Windows-Desktop-Betriebssystem, die auf einem für Background Services eingerichteten Server-Betriebssystem ungefähr 187.500000 beträgt Frau.

Beobachtung/Erklärung

Wenn Sie die Einstellung auf einem Server oder Desktop von "Hintergrunddienste" in "Anwendungen" ändern, wird in der Registrierung der Schlüssel HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl\Win32PrioritySeparation verwendet wird von 0x18 auf 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" die Standardeinstellung für das Betriebssystem sind.

Die Standardeinstellung für diese Felder für XPe & XP Pro ist: Short & Variable, was dem Setzen der folgenden zusätzlichen Bits entspricht: 0x24.

Wenn Sie diesen Wert mit 0x02 eingeben, 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

Basierend auf den obigen Informationen und Artikelzitaten wissen wir, dass ein Quantum keine feste Größe hat, sondern von einer Betriebssystemeinstellung in den Systemeigenschaften abgeleitet ist. Ein Quantum variiert je nach Win32PrioritySeparation Einstellung in der Registrierung, die normalerweise einer der Einstellungen in den "Systemeigenschaften" entspricht (entweder "Hintergrunddienste" oder "Anwendungen").

Ein Quantum auf OS-Ebene ist

  • für die Einstellung "Anwendungen"
    • 18 (das sind 6 Ticks) für Vordergrundanwendungen (93,75 ms)
    • 6 (which is 2 ticks) for background applications (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 Betriebssystemquantum in einem Windows Server-Setup, das für Hintergrunddienste optimiert werden soll, ...

36 / 3 * 15.625000 ms = 187.5 ms

SQL OS Quantum

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

SOS_SCHEDULER_YIELD Wartetyp

Aus Paul Randalls Beschreibung des SOS_SCHEDULER_YIELD-Wartetyps:

Dieser Wartetyp ist, wenn ein Thread in der Lage war, sein vollständiges Thread-Quantum (4 Millisekunden in allen Versionen von SQL Server, unveränderlich ) auszuführen, und so freiwillig den Scheduler ergab und zu wechselte Das Ende der ausführbaren Warteschlange in ihrem Scheduler.

Referenz :SOS_SCHEDULER_YIELD (SQLSkills.com Wait Types)

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 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, aber nicht zur Ausführung bereit ist, seine Zeitmenge zugunsten anderer Threads liefern kann.

Referenz :Grundlegendes zu SQL Server-Schedulern, -Arbeitern und -Aufgaben (MSSQLTips.com)

Erkennen Sie den SQL Server-CPU-Druck

Dies ist ein sehr kleiner Abschnitt eines Artikels zum CPU-Druck in SQL Server.

Tritt auf, wenn eine Aufgabe freiwillig den Scheduler für die Ausführung anderer Aufgaben liefert. Während dieser Wartezeit wartet die Task darauf, dass ihr Quantum erneuert wird .

Referenz :SQL Server-CPU-Druck erkennen (MSSQLTips.com)

sys.dm_os_schedulers (Microsoft Docs)

Ich denke, das folgende Zitat ist der wichtigste Ausschnitt von Informationen bezüglich des SQL OS-Quantums, 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 OS Quantum regelt, wie viel Zeit dem SQL Server-Dienst zur Ausführung von "Aufgaben" gewährt wird. Das SQL Server OS Quantum ist als 4 ms definiert. Wenn ich die 187,5 ms durch 4 ms dividiere, bleiben 3,5 ms übrig.

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

Einfache Frage

Wie wird das 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-Quanten entspricht), hat das OS-Quantum 3,5 ms Zeit, bevor es den Zeitplan einem anderen Prozess übergeben muss. Das SQL-Betriebssystem startet ein Quantum (4 ms) und nach 3,5 ms hat das Betriebssystem-Quantum beschlossen, den aktuellen SQL-OS-Thread zu stoppen, der noch 0,5 ms hat, bevor er den Zeitplan ergibt. Was passiert jetzt?

19

Auch wenn der Scheduler nicht präventiv ist, hält der SQL Server-Scheduler dennoch an einem Quantenkonzept fest. Wenn SQL Server-Tasks gezwungen sind, die CPU vom Betriebssystem aufzugeben, können sie anfordern, regelmäßig in eine Warteschlange gestellt zu werden. Wenn sie das intern definierte 4-Millisekunden-Quantum überschritten haben und sich nicht mitten in einer Operation befinden das kann nicht gestoppt werden, sie geben freiwillig die CPU ab.

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

-Kapitel 2 "Das SQLOS" Jonathan Kehayias

Der Begriff "Quantum" in SQL Server ist also eher eine "Richtlinie" für Programmieraufgaben. IE wenn Sie eine Aufgabe schreiben, z. B. eine Aufgabe, die einen Tabellenscan durchführt, wenn Sie keinen Seiten-Latch treffen, IO Latch oder Die Sperre wartet eine Weile. Sie sollten aufhören, was Sie tun, und darum bitten, wieder in die ausführbare Warteschlange gestellt zu werden, falls andere Aufgaben warten.

Aber es liegt an dem Task-Programmierer, dies zu implementieren, und es kann sein, dass es nicht gena 4 ms für jede Art von Task ist. Beispielsweise kann die Tabellenscanaufgabe eine einfache Heuristik verwenden, die auf der Anzahl der gescannten Seiten basiert, um die Fließgrenzen zu implementieren.

Damit

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

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

Beantworte Beiträge, die ursprünglich als Kommentare hinterlassen wurden

Wie wird das 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. Es wird erwartet, dass Arbeitselemente Ertragspunkte erreichen, und wenn dies nicht der Fall ist, erhalten Sie Dinge wie NONYIELDING Scheduler. 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 ein Stück Zeit. Das ist es. SQL Server ist nicht präventiv, es liegt in der Verantwortung von allem, was ausgeführt wird, sich im gesamten Code zu behaupten. - Sean Gallardy

Wenn das OS-Quantum abläuft, wird der Thread zwangsweise deaktiviert. Dies ist für SQL Server transparent. SQLOS kann nicht erkennen, wann dies geschieht. Dafür gibt es keine Win32-API. Die Planung ist für Threads im Benutzermodus transparent. Der Windows-Scheduler weiß nicht, welche Threads im Benutzermodus ausgeführt werden. Windows sieht nur Threads, die ausgeführt werden können, und lässt sie bis zum Ende ihres Betriebssystemquantums oder bis zum Blockieren ausgeführt werden. - sr

In mgang mit übermäßigen SOS_SCHEDULER_YIELD-Wartetypwerten in SQL Server von Nikola Dimitrijevic bedeutet der Begriff "Quantum" im Wesentlichen "die Zeit, die eine Aufgabe tatsächlich einem Mitarbeiter zuweist", aber das ist nicht die Dies bedeutet auch ein Windows-Quantum. Dies ist eine Zeitspanne, nach der das Betriebssystem einen Thread aus einer CPU entfernt. Sie sind nur verschiedene Konzepte. Wenn das Betriebssystem einen Thread zwingt, die Ausführung zu beenden, weil das Betriebssystemquantum erreicht wurde, erfolgt ein Kontextwechsel. Der SQL Server-Thread wird wie jedes andere Programm angehalten. - David Browne - Microsoft und George.Palacios .


Auszüge aus der Dokumentation: Im SQL Server 2000-Benutzermodus-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 verfolgt den Ansatz, um zu verhindern, dass der Windows-Kernel mehr als unbedingt erforderlich einbezogen wird. In einem System, in dem man darauf zählen kann, dass Worker-Threads nachgeben, wann sie sollten, kann ein kooperativer Scheduler tatsächlich effizienter sein als ein präventiver, da der Scheduling-Prozess auf die spezifischen Anforderungen der Anwendung zugeschnitten werden kann. Wie ich bereits sagte, kennt UMS die Planungsanforderungen von SQL Server besser als vom Betriebssystem erwartet.

Wie UMS die Planung übernimmt

Wenn UMS die Planungsanforderungen von SQL Server erfüllen soll, anstatt Windows dies zuzulassen, muss UMS das Betriebssystem irgendwie daran hindern, das zu tun, was es mit jedem anderen Prozess tut: Threads auf und von den Prozessoren des Systems nach eigenem Ermessen planen. Wie macht man das in einem präventiven Betriebssystem? UMS schafft dies durch einige clevere Tricks mit Windows-Ereignisobjekten. Jedem Thread unter UMS ist ein Ereignisobjekt zugeordnet. Für Planungszwecke ignoriert Windows Threads, die es nicht für funktionsfähig hält - Threads, die nicht ausgeführt werden können, weil sie sich in einem unendlichen Wartezustand befinden. In diesem Wissen versetzt UMS Threads in den Ruhezustand, die nicht geplant werden sollen, indem sie WaitForSingleObject für das entsprechende Ereignisobjekt aufrufen und [~ # übergeben ~] unendlich [~ # ~] für den Timeout-Wert.

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

4
user126897