簡単な質問

SQL Server Quantum（4 ms）とServer OS Quantum（通常：187.5 ms）はどのように同期しますか？

簡単な質問の説明

184ミリ秒のOSクォンタム（46の完全なSQLクォンタムに対応）が使用された後、OSクォンタムには3.5ミリ秒の時間が経過してから、スケジュールを別のプロセスに引き渡す必要があります。SQL OSはクォンタム（4ミリ秒）を開始し、3.5ミリ秒後、OSクォンタムは、スケジュールを生成する前に0.5ミリ秒残っている現在のSQL OSスレッドを停止することを決定しました。今、何が起きた？

---

OS Quantumの詳細

次のいくつかのセクションでは、OSクォンタムに関してこれまでに発見したことと、クォンタムの継続時間を計算する方法について説明します。OSの「クォンタム」の持続時間は「ティック」に基づいており、「ティック」自体の持続時間は「クロック間隔」に基づいており、通常は15.625000ミリ秒です。しかし、少し詳しく説明させてください...

ダニ

ブログの記事Know Know Thy Tickで、著者Jimはクロック間隔（別名「ティック」）の基本とその目的について説明しています。

「ほとんどのx86マルチプロセッサのクロックインターバルは約15ミリ秒です」などと読んだとき、クロックの値、つまり「ティック」のインターバルを決定せざるを得ません。幸いなことに、この引用を読んだ本であるWindows Internals Fourth Editionは、私の悩みを解決するための参考資料となります。...前述の本の著者であるMark Russinovichは、彼のWebサイトでユーティリティClockResを利用できるようにしてくれました。このユーティリティを実行すると、x86マルチプロセッサPCのクロック間隔が15.625000ミリ秒であることがわかりました。興味深いが、私の好奇心はもっと知りたい。

量子

記事の著者は、2番目の記事で説明を続けています。 それ...

もちろん、ティック間隔が重要である本当の理由は、それがスレッドのスケジューリングに影響することです。Windowsスケジューラーは、各スレッドに実行する「量子」時間を与えてから、同じ優先度レベルの別のタスクの実行を許可します。スケジューラーがスレッドに割り当てるクォンタムは、ティック間隔の倍数です。特定のスレッドに選択された特定のクォンタム値は、この記事で説明したいところを少し超えています。

OK

とりあえず、XPeのフォアグラウンドスレッドのデフォルトのクォンタム値を調べてみましょう。この場合、Windowsスケジューラは18または6ティック間隔のクォンタムを割り当てます。（はい、クォンタムをティック間隔に変換するには、3で除算する必要があります。ただし、複数の理由は、スケジューラーがスレッドを一時停止させる操作を行うためにスレッドを「チャージ」できるようにするためです。）

クロック間隔（ティック）は約15.625000ミリ秒であり、デフォルトのクォンタムが18であるWindowsデスクトップOSでは6ティックまたは93.750000ミリ秒（18/3 * 15.625000ミリ秒）になることがわかっています。

Windows Server OSでは、デフォルトのクォンタムは異なります。「プロセッサのスケジューリング」設定が「バックグラウンドサービス」に設定されている

^{この設定は、「システム設定|詳細（タブ）|パフォーマンス（セクション）|設定...」で確認できます。「パフォーマンスオプション|詳細（タブ）|プロセッサスケジューリング」が開きます。}

デフォルトのクォンタム設定は、36（バックグラウンド）から36（フォアグラウンド）です。量子はより大きく、したがってより長くなります。これは、WindowsデスクトップOSの18（6ティック）クォンタムフォアグラウンド設定の93.750000ミリ秒の2倍の量であり、バックグラウンドサービス用に設定されたサーバーOSでは約187.500000ミリ秒です。

観察/説明

サーバーまたはデスクトップで「バックグラウンドサービス」から「アプリケーション」に設定を変更すると、レジストリのHKLM \ SYSTEM \ CurrentControlSet \ Control \ PriorityControl \ Win32PrioritySeparationキーが0x18から0x02に変更されます。0x02のデフォルトの量子値は何ですか？これはコメントで見つけることができます：

値0x02は、「短対長」および「変数対固定」フィールドがOSのデフォルトであることを意味します。

XPeおよびXP Proのこれらのフィールドのデフォルトは次のとおりです。Short＆Variable。次のビットを追加するビットを設定するのと同じです：0x24。

この値を0x02とORすると、0x26が得られます。これは、記事の表にあります。

^{参照：「Master Your Quantum」へのコメント（MSDNブログ）}

同じ記事のクォンタム設定を説明する表：

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

OS Quantumの簡単な要約

上記の情報と記事の引用に基づいて、クォンタムは固定サイズではなく、システムプロパティのOS設定から派生していることがわかります。クォンタムは、Win32PrioritySeparation通常は「システムプロパティ」（「バックグラウンドサービス」または「アプリケーション」）の設定のいずれかに対応するレジストリの設定によって異なります。

OSレベルのクォンタムは

• 「アプリケーション」設定用
  • フォアグラウンドアプリケーションの場合は18（6ティック）（93.75ミリ秒）
  • バックグラウンドアプリケーションの場合は6（2ティック）（31.25ミリ秒）
• 「バックグラウンドサービス」設定用
  • フォアグラウンドアプリケーションでは36（18ティック）（187.5ミリ秒）
  • バックグラウンドアプリケーションの場合は36（18ティック）（187.5ミリ秒）

これで、バックグラウンドサービス用に最適化されるWindows ServerセットアップのOSクォンタムが...

36 / 3 * 15.625000 ms = 187.5 ms

---

SQL OSクォンタム

このセクションでは、SQL OSクォンタムで見つけたものをリストします...

SOS_SCHEDULER_YIELD待機タイプ

SOS_SCHEDULER_YIELD待機タイプに関するPaul Randallの説明から：

この待機タイプは、スレッドが完全なスレッドクォンタム（SQL Serverのすべてのバージョンで4ミリ秒、変更不可）で実行できたため、自発的にスケジューラを生成し、スケジューラのRunnableキューの下部に移動したときです。

^{参照：SOS_SCHEDULER_YIELD（SQLSkills.comの待機タイプ）}

SQL Server DMVのスケジューラー

sys.dm_os_schedulers DMVのSQL Server DMVの説明。

[...] Windowsはプリエンプティブスケジューリングメカニズムを使用して、CPU時間のクォンタムをすべてのスレッドに割り当てます。スレッドがクォンタムを消費すると、キューに送信され、他のスレッドに実行が許可されます。

反対に、SQL Serverは、スレッドが自発的に時間のクォンタムを獲得できる場合、協調スケジューリングメカニズムを使用します（SOS_SCHEDULER_YIELD待機タイプがある場合、この動作を確認できます）。これにより、SQL ServerはCPU使用率を最適化できます。これは、スレッドが実行のために通知されても実行準備が整っていない場合、他のスレッドに有利な時間のクォンタムが得られるためです。

^{参照：SQL Serverスケジューラ、ワーカー、およびタスクについて（MSSQLTips.com）}

SQL ServerのCPUプレッシャーを検出する

これは、SQL ServerのCPUプレッシャーに関する記事の非常に小さなセクションです。

タスクが、実行する他のタスクのスケジューラを自発的に譲り渡すときに発生します。この待機中、タスクはクォンタムが更新されるのを待っています。

^{リファレンス：SQL Server CPUプレッシャーの検出（MSSQLTips.com）}

sys.dm_os_schedulers（Microsoft Docs）

次の引用は、私が見つけることができるSQL OSクォンタムに関する情報の最も重要なスニペットだと思います。

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

^{リファレンス：sys.dm_os_schedulers（Transact-SQL）（Microsoft | Docs）}

---

私の難問

サーバーOSクォンタムは、SQL Serverサービスが「タスク」の実行に許可される時間を規制します。SQL Server OS Quantumは4ミリ秒として定義されています。187.5ミリ秒を4ミリ秒で除算すると、3.5ミリ秒が残ります。

また、Clock Intervalがデフォルトの15.625000ミリ秒以外に設定されている場合についての議論も開始していません。

簡単な質問

SQL Server Quantum（4 ms）とサーバーOS Quantum（通常：187.5 ms）はどのように同期しますか？

簡単な質問の説明

184ミリ秒のOSクォンタム（46の完全なSQLクォンタムに対応）が使用された後、OSクォンタムには3.5ミリ秒の時間が経過してから、スケジュールを別のプロセスに引き渡す必要があります。SQL OSはクォンタム（4ミリ秒）を開始し、3.5ミリ秒後、OSクォンタムは、スケジュールを生成する前に0.5ミリ秒残っている現在のSQL OSスレッドを停止することを決定しました。今、何が起きた？

スケジューラーはプリエンプティブではありませんが、SQL Serverスケジューラーはクォンタムの概念に準拠しています。SQL ServerタスクよりもオペレーティングシステムによってCPUを放棄せざるを得ないため、定期的に待機キューに入れるように要求できます。また、内部で定義された4ミリ秒のクォンタムを超えており、操作の途中にない場合それを止めることはできず、CPUを自発的に放棄します。

-「Microsoft SQL Server 2012 Internals」、Kalen Delaney et。al。pp38

-第2章「SQLOS」Jonathan Kehayias

したがって、SQL Server内の「クォンタム」という概念は、プログラミングタスクの「ガイドライン」に近いものです。IE、たとえばテーブルスキャンを実行するタスクを作成するとき、ページラッチ、IOラッチ、またはロック待機をしばらくヒットしない場合は、実行中の操作を停止して、他のタスクが待機している場合に備えて、実行可能なキューに戻します。

しかし、これを実装するのはタスクプログラマー次第であり、タスクの種類ごとに正確に 4msになるとは限りません。たとえば、テーブルスキャンタスクでは、スキャンされたページ数に基づいた単純なヒューリスティックを使用して、降伏ポイントを実装できます。

そう

SQL OSはクォンタム（4ミリ秒）を開始し、3.5ミリ秒後、OSクォンタムは、スケジュールを生成する前に0.5ミリ秒残っている現在のSQL OSスレッドを停止することを決定しました。今、何が起きた？

SQL Serverスレッドがタスクの実行中にWindowsによって横取りされると、一時停止され、そのスレッドがCPUで次にスケジュールされたときに、中断したところから続行されます。おそらく違いを知らないので、4msのクォンタムのバランスを消費し続けるでしょう。ただし、yieldの動作は、SQLOSの動作ではなく、タスクの実装の詳細であるため、ここでは異なるタスクの動作が異なる場合があります。

_{元々コメントとして残された貢献に回答する}

SQL Server Quantum（4 ms）とServer OS Quantum（通常：187.5 ms）はどのように同期しますか？

そうではなく、SQL Serverはプリエンプティブスケジューリングを使用しません。作業項目は降伏点に到達することが期待されており、到達しない場合は、NONYIELDINGスケジューラーなどが取得されます。パリティはありません。SQL Serverは時間を配布しません。特定のスレッドをWindowsにとって魅力的なものにし、Windowsがそれらをスケジュールします。クォンタムは一時的な命名法です。それでおしまい。SQL Serverはプリエンプティブではありません。実行中のすべてのコードがコード全体に影響を与える責任があります。– ショーンギャラディー

OSクォンタムの有効期限が切れると、スレッドは強制的にスケジュール解除されます。これは、SQL Serverに対して透過的です。SQLOSには、これが発生したことを検出する方法がありません。そのためのWin32 APIはありません。スケジューリングは、ユーザーモードスレッドに対して透過的です。Windowsスケジューラは、ユーザーモードスレッドが何をしているのかを知りません。Windowsは、実行可能なスレッドのみを認識し、OSクォンタムの最後まで、またはブロックするまで実行できるようにします。– usr

ではSQL Serverでの過度のSOS_SCHEDULER_YIELD待機型の値をどのように扱うかニコラDimitrijevicにより、用語「量子」は、基本的に、それは、Windowsの量子と同じ感覚ではないのです「タスクは、実際に作業員に割り当てられている時間」を意味するために使用されますOSがCPUからスレッドを削除するまでの期間です。それらは異なる概念です。OSクォンタムに達したためにOSがスレッドの実行を強制終了すると、コンテキストの切り替えが発生します。SQL Serverのスレッドは、他のプログラムと同様に中断されます。– David Browne- マイクロソフトとGeorge.Palacios。

---

ドキュメントからの抜粋：SQL Server 2000ユーザーモードスケジューラー内（SQL Server 2000用に作成されていますが、引き続き関連しています）：

プリエンプティブと協調タスク

対照的に、UMSはスレッドに依存して自発的に結果を出します。UMSは、絶対に必要な以上にWindowsカーネルに関与しないようにするためのアプローチを採用しています。ワーカースレッドは、必要なときに解放するためにカウントできるシステムでは、スケジューリングプロセスをアプリケーションの特定のニーズに合わせて調整できるため、協調スケジューラは実際にはプリエンプティブスケジューラよりも効率的です。前述したように、UMSは、オペレーティングシステムが期待できるよりもSQL Serverのスケジューリングのニーズをよく知っています。

UMSがスケジューリングを引き継ぐ方法

UMSがWindowsに許可するのではなく、SQL Serverのスケジューリングニーズを処理する場合、UMSは何らかの方法でOSが他のすべてのプロセスで実行することを防止する必要があります：システムのプロセッサのスレッドを適切にスケジュールします。プリエンプティブOSでそれをどのように行いますか？UMSは、Windowsイベントオブジェクトを使用した巧妙なトリックによってこれを実現します。UMSの下の各スレッドには、イベントオブジェクトが関連付けられています。スケジューリングの目的で、Windowsは実行可能とは見なさないスレッド、つまり無限の待機状態にあるために実行できないスレッドを無視します。これを知って、UMSは、対応するイベントオブジェクトでWaitForSingleObjectを呼び出し、タイムアウト値にINFINITEを渡すことで、スレッドがスケジュールされないようにスリープ状態にします。

Windowsが同じプロセッサ上で複数のスレッドをスケジュールし、それによってコンテキスト切り替えのオーバーヘッドと費用が発生するのを防ぐため、UMSはプロセッサごとに1つのスレッドのみを実行可能（つまり、無限の待機状態ではない）にしようとします。