Windows OS Quantum vs. SQL OS Quantum


19

Proste pytanie

W jaki sposób SQL Server Quantum (4 ms) jest synchronizowany z Server OS Quantum (normalnie: 187,5 ms)?

Proste pytanie wyjaśnione

Po użyciu 184 ms kwantu OS (co odpowiada 46 pełnym kwantom SQL) kwant OS ma 3,5 ms czasu, zanim będzie musiał przekazać harmonogram innemu procesowi. SQL OS rozpoczyna kwant (4 ms), a po 3,5 ms kwant OS zdecydował zatrzymać bieżący wątek SQL OS, który wciąż ma 0,5 ms, zanim wygeneruje harmonogram. Co się teraz stanie?


Deep Dive na OS Quantum

W następnych kilku rozdziałach napiszę, co do tej pory znalazłem na temat kwantu OS i jak można obliczyć czas trwania kwantu. Czas trwania „kwantu” systemu operacyjnego oparty jest na „tyknięciach”, a sam „tyknięcie” opiera się na „interwale zegarowym”, który zwykle wynosi 15.625000 ms. Ale pozwól mi rozwinąć trochę ...

Kleszcz

W artykule na blogu Know Thy Tick autor Jim wyjaśnia podstawy interwałów zegara (aka „tyknięcia”) i do czego służą.

Kiedy czytam coś w stylu „interwał zegara… dla większości procesorów x86 wynosi około 15 milisekund”, jestem zmuszony określić wartość mojego zegara lub „tik”, interwał. Na szczęście książka, w której przeczytałem ten cytat, Windows Internals Fourth Edition zawiera informacje pomocne w moim schorzeniu. ... Autor, Mark Russinovich, wspomnianej książki z wdzięcznością udostępnił narzędzie ClockRes na swojej stronie internetowej. Korzystając z tego narzędzia, udało mi się ustalić, że interwał zegara na moim komputerze wieloprocesorowym x86 wynosi 15.625000 ms. Ciekawe, ale mój ciekawy umysł chce wiedzieć więcej.

Kwant

Autor artykułu wyjaśnia dalej w swoim drugim artykule że...

Oczywiście prawdziwym powodem, dla którego interwał tykania jest ważny, jest to, że wpływa on na planowanie wątków . Harmonogram systemu Windows daje każdemu wątkowi „kwant” czasu do wykonania przed zezwoleniem na uruchomienie innego zadania na tym samym poziomie priorytetu. Kwant, który planista przypisuje do wątku, jest wielokrotnością interwału tykania . Konkretna wartość kwantowa wybrana dla konkretnego wątku jest nieco większa niż w tym artykule.

Ok, więc wiem, co to jest kwant, ale nie wiem, jak długo kwant będzie działał.

Na razie zbadajmy domyślną wartość kwantową dla wątku pierwszego planu w XPe. W takim przypadku program planujący systemu Windows przypisuje kwant 18 lub 6 odstępów tykania. (Tak, aby przekonwertować kwant na interwały tykania, należy podzielić przez 3. ..., ale powodem wielokrotności jest umożliwienie planistowi możliwości „obciążenia” wątku za wykonanie operacji, która powoduje jego zawieszenie.)

Wiemy teraz, że interwał zegara (tyknięcie) powinien wynosić około 15,625000 ms, a w systemie operacyjnym Windows Desktop, gdzie domyślnym kwantem jest 18, spowoduje to 6 tyknięć lub 93,750000 ms (18/3 * 15,625000 ms).

W systemie operacyjnym Windows Server domyślny kwant jest inny. Ustawienie „Planowanie procesora” jest ustawione na „Usługi w tle”

To ustawienie można znaleźć w „Ustawieniach systemu | Zaawansowane (zakładka) | Wydajność (sekcja) | Ustawienia ...”, które otworzą „Opcje Perofrmance | Zaawansowane (zakładka) | Planowanie procesora”

Domyślne ustawienia kwantowe to od 36 (Tło) do 36 (Pierwszy plan). Kwant jest większy, a zatem dłuższy. Jest to dwukrotność kwoty 93,750000 ms z 18 (6 tyknięć) kwantowych ustawień pierwszego planu w systemie operacyjnym Windows Desktop, który w systemie operacyjnym serwera skonfigurowanym dla usług w tle wynosi około 187,500000 ms.

Obserwacja / objaśnienie

Po zmianie ustawienia z „Usługi w tle” na „Applicaitons” na serwerze lub komputerze stacjonarnym klucz HKLM \ SYSTEM \ CurrentControlSet \ Control \ PriorityControl \ Win32PrioritySeparation w rejestrze zmienia się z 0x18 na 0x02. Jaka jest domyślna wartość kwantowa dla 0x02? Można to znaleźć w komentarzu:

Wartość 0x02 oznacza, że ​​pola „Krótki kontra długi” i „Zmienny vs. stały” są domyślnymi ustawieniami dla systemu operacyjnego.

Domyślnie dla tych pól dla XPe i XP Pro są: Krótkie i zmienne, co jest tym samym, co ustawienie następujących bitów dodatkowych bitów: 0x24.

LUB użycie tej wartości w 0x02 daje 0x26, które znajdziesz w tabeli w artykule.

Odniesienie: Komentarz do „Opanuj swoje kwantowe” (blogi MSDN)

Tabela wyjaśniająca ustawienia kwantowe z tego samego artykułu:

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

Krótkie podsumowanie systemu operacyjnego Quantum

W oparciu o powyższe informacje i cytaty z artykułów wiemy, że kwant nie jest stałym rozmiarem, lecz pochodzi z ustawienia systemu operacyjnego we właściwościach systemu. Kwant różni się w zależności od Win32PrioritySeparationustawienia w rejestrze, które zwykle odpowiada jednemu z ustawień we „Właściwościach systemu” („Usługi w tle” lub „Aplikacje”).

Kwant na poziomie systemu operacyjnego to

  • dla ustawienia „Aplikacje”
    • 18 (czyli 6 znaczników) dla aplikacji pierwszego planu (93,75 ms)
    • 6 (czyli 2 tiki) dla aplikacji działających w tle (31,25 ms)
  • dla ustawienia „Usługi w tle”
    • 36 (czyli 18 tyknięć) dla aplikacji na pierwszym planie (187,5 ms)
    • 36 (czyli 18 tyknięć) dla aplikacji działających w tle (187,5 ms)

Teraz wiemy, że kwant systemu operacyjnego w konfiguracji systemu Windows Server, który ma być zoptymalizowany pod kątem usług w tle, jest ...

36 / 3 * 15.625000 ms = 187.5 ms

SQL OS Quantum

W tej sekcji wymieniono to, co znalazłem na kwantowym SQL OS ...

SOS_SCHEDULER_YIELD Typ oczekiwania

Z opisu Paula Randalla na SOS_SCHEDULER_YIELD typ oczekiwania:

Ten typ oczekiwania występuje, gdy wątek był w stanie wykonać pełny kwant wątku (4 milisekundy we wszystkich wersjach SQL Server, niezmienne ), a więc dobrowolnie dał harmonogram, przechodząc na dół kolejki Runnable w swoim harmonogramie.

Odniesienie: SOS_SCHEDULER_YIELD (typy oczekiwania SQLSkills.com)

Harmonogramy w DMV SQL Server

W objaśnieniu DMV dla SQL Server dla DMV sys.dm_os_schedulers.

[...] Windows korzysta z wyprzedzającego mechanizmu planowania i przypisuje kwant czasu procesora do każdego wątku, gdy wątek zużyje jego kwant, jest wysyłany do kolejki, a inne wątki mają zapewnione wykonanie.

Przeciwnie, SQL Server używa mechanizmu planowania współpracy, gdy wątki mogą dobrowolnie wydać swój czas (możesz zobaczyć to zachowanie, gdy masz typ oczekiwania SOS_SCHEDULER_YIELD). Pozwala to SQL Serverowi zoptymalizować wykorzystanie procesora, ponieważ gdy wątek jest sygnalizowany do wykonania, ale nie jest gotowy do uruchomienia, może poświęcić swój czas na korzyść innych wątków .

Odwołanie: Zrozumienie harmonogramów, pracowników i zadań programu SQL Server (MSSQLTips.com)

Wykryj ciśnienie procesora serwera SQL

To jest bardzo mała część artykułu na temat obciążenia procesora w SQL Server.

Występuje, gdy zadanie dobrowolnie daje harmonogramowi inne zadania do wykonania. Podczas tego oczekiwania zadanie czeka na odnowienie swojego kwantu .

Odwołanie: Wykryj ciśnienie procesora serwera SQL (MSSQLTips.com)

sys.dm_os_schedulers (Dokumenty Microsoft)

Myślę, że następujący cytat jest najważniejszym fragmentem informacji dotyczących kwantowej wersji SQL OS, którą mogłem znaleźć:

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

Odwołanie: sys.dm_os_schedulers (Transact-SQL) (Microsoft | Docs)


Moja zagadka

System operacyjny serwera Quantum reguluje, ile czasu usługa SQL Server ma na wykonanie „zadań”. SQL Server OS Quantum jest zdefiniowany jako 4 ms. Jeśli podzielę 187,5 ms przez 4 ms, pozostanie mi 3,5 ms.

I nawet nie rozpoczęliśmy dyskusji, kiedy interwał zegara jest ustawiony na coś innego niż domyślny 15,625000 ms ....

Proste pytanie

W jaki sposób SQL Server Quantum (4 ms) jest synchronizowany z Server OS Quantum (normalnie: 187,5 ms)?

Proste pytanie wyjaśnione

Po użyciu 184 ms kwantu OS (co odpowiada 46 pełnym kwantom SQL) kwant OS ma 3,5 ms czasu, zanim będzie musiał przekazać harmonogram innemu procesowi. SQL OS rozpoczyna kwant (4 ms), a po 3,5 ms kwant OS zdecydował zatrzymać bieżący wątek SQL OS, który wciąż ma 0,5 ms, zanim wygeneruje harmonogram. Co się teraz stanie?

Odpowiedzi:


13

Mimo że program planujący nie ma charakteru wyprzedzającego, program SQL Server nadal stosuje koncepcję kwantową. Zadania bardziej niż zadania programu SQL Server są zmuszane do rezygnacji z procesora przez system operacyjny, mogą okresowo żądać umieszczenia w kolejce oczekiwania, a jeśli przekroczą wewnętrznie zdefiniowane 4 milisekundy i nie są w trakcie operacji którego nie można zatrzymać, dobrowolnie rezygnują z procesora.

- „ Microsoft SQL Server 2012 Internals ”, Kalen Delaney i in. glin. pp38

-Rozdział 2 „SQLOS” Jonathan Kehayias

Pojęcie „kwantowe” w SQL Server jest raczej „wytyczną” do zadań programistycznych. IE, gdy piszesz zadanie, np. Zadanie, które wykonuje skanowanie tabeli, jeśli nie wciśniesz żadnego zatrzasku strony, zatrzasku IO lub blokady, czeka na chwilę, powinieneś przerwać to, co robisz i poprosić o bycie umieść z powrotem w kolejce do uruchomienia, na wypadek, gdyby czekały inne zadania.

Ale programista zadania musi to zaimplementować i może to nie być dokładnie 4 ms dla każdego rodzaju zadania. Na przykład zadanie skanowania tabeli może wykorzystywać prostą heurystykę opartą na liczbie skanowanych stron w celu zaimplementowania granic wydajności.

Więc

SQL OS rozpoczyna kwant (4 ms), a po 3,5 ms kwant OS zdecydował zatrzymać bieżący wątek SQL OS, który wciąż ma 0,5 ms, zanim wygeneruje harmonogram. Co się teraz stanie?

Jeśli wątek programu SQL Server zostanie uprzednio opróżniony przez system Windows podczas wykonywania zadania, zostanie on wstrzymany, a gdy jego wątek zostanie następnie zaplanowany na procesorze, będzie kontynuowany w miejscu, w którym został przerwany. Przypuszczalnie będzie nadal zużywał równowagę swojego kwantu 4ms, ponieważ nie poznałby żadnej różnicy. Ale znowu zachowanie wydajności jest szczegółem implementacji zadania, a nie zachowaniem SQLOS, więc różne zadania mogą tutaj zachowywać się inaczej.


4

Odpowiedzi na komentarze pozostawione pierwotnie jako komentarze

W jaki sposób SQL Server Quantum (4 ms) jest synchronizowany z Server OS Quantum (normalnie: 187,5 ms)?

Tak nie jest, a SQL Server nie korzysta z wyprzedzającego planowania. Oczekuje się, że elementy pracy osiągną punkty wydajności, a jeśli nie, otrzymasz takie rzeczy, jak NONYIELDINGharmonogramy. Nie ma parytetu. SQL Server nie rozdziela czasu. To sprawia, że ​​pewne wątki są atrakcyjne dla systemu Windows do planowania, a Windows je planuje. Kwant to tylko nomenklatura na pewien czas. Otóż ​​to. SQL Server nie ma charakteru wyprzedzającego, jest odpowiedzialny za wszystko, co działa, aby ustąpić w całym kodzie. - Sean Gallardy

Kiedy kwant systemu operacyjnego wygaśnie, wątek zostanie wymuszony. Jest to przezroczyste dla SQL Server. SQLOS nie ma możliwości wykrycia, kiedy to nastąpi. Nie ma do tego API Win32. Planowanie jest przejrzyste dla wątków trybu użytkownika. Program planujący systemu Windows nie wie ani nie obchodzi, co robią wątki trybu użytkownika. Windows widzi tylko wątki, które można uruchomić i pozwala im działać do końca kwantowego systemu operacyjnego lub do momentu zablokowania. - usr

W Jak poradzić sobie z nadmiernymi wartościami typu oczekiwania SOS_SCHEDULER_YIELD w SQL Server autorstwa Nikoli Dimitrijevica, termin „kwant” jest używany w zasadzie „czas, który zadanie faktycznie przypisuje robotnikowi”, ale to nie to samo, co kwant systemu Windows, czyli czas, po którym system operacyjny usunie wątek z procesora. To tylko różne koncepcje. Jeśli system operacyjny zmusi wątek do zakończenia wykonywania, ponieważ kwant systemu operacyjnego został osiągnięty, nastąpi zmiana kontekstu. Wątek programu SQL Server jest zawieszony, podobnie jak każdy inny program. - David Browne - Microsoft i George.Palacios .


Fragmenty dokumentacji: Wewnątrz harmonogramu trybu użytkownika programu SQL Server 2000 (napisanego dla programu SQL Server 2000, ale nadal istotnego):

Zadania wyprzedzające a kooperacyjne

Z kolei UMS polega na wątkach, które dają się dobrowolnie. UMS przyjmuje takie podejście, aby nie angażować jądra systemu Windows bardziej niż to absolutnie konieczne. W systemie, w którym wątki robocze można liczyć na wydajność, kiedy powinny, harmonogram współpracujący może być faktycznie bardziej wydajny niż zapobiegawczy, ponieważ proces planowania można dostosować do konkretnych potrzeb aplikacji. Jak powiedziałem wcześniej, UMS lepiej zna potrzeby SQL Server dotyczące planowania niż system operacyjny.

Jak UMS przejmuje planowanie

Jeśli UMS ma obsługiwać potrzeby SQL Server dotyczące planowania, zamiast pozwolić Windowsowi na to, UMS musi w jakiś sposób uniemożliwiać systemowi operacyjnemu robienie tego, co robi z każdym innym procesem: planować włączanie i wyłączanie wątków procesora (procesorów) według własnego uznania. Jak to zrobić w systemie wyprzedzającym? UMS wyciąga to poprzez kilka sprytnych sztuczek z obiektami zdarzeń Windows. Każdy wątek w UMS ma powiązany obiekt zdarzenia. Do celów planowania system Windows ignoruje wątki, których nie uważa za wykonalne - wątki, które nie mogą działać, ponieważ są w nieskończonym stanie oczekiwania. Wiedząc o tym, UMS uśpia wątki, których nie chce planować, poprzez wywołanie WaitForSingleObject na odpowiednim obiekcie zdarzenia i przekazanie INFINITE dla wartości limitu czasu.

Aby uniemożliwić systemowi Windows zaplanowanie wielu wątków na tym samym procesorze, a tym samym ponieść koszty ogólne i koszty przełączników kontekstu, UMS stara się utrzymać żywotność tylko jednego wątku - to znaczy nie w nieskończonym stanie oczekiwania - na procesor.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.