自分のメモとなるのですが SQL Server で Non-yielding scheduler のエラーが発生した場合に必要となる情報をまとめておきたいと思います。
SQL Server のスケジューラーの切り替えの制御は スレッドおよびタスクのアーキテクチャ ガイド に記載されている動作となり、ドキュメントには次のように記載されています。
各スケジューラは、個々のプロセッサ (CPU) にマップされます。 ワーカーがスケジューラでアクティブな状態を維持できる時間は、OS クォンタムと呼ばれ、最大 4 ミリ秒です。
基本的には連続して CPU を使用するのは 4 ミリ秒となっており、その時間を超えた場合には他のワーカーに使用権を明け渡し、再度 CPU の使用権が受け取れた時に処理を再開するというサイクルを繰り返します。
何らかの要因により、CPU の使用権を譲渡せず、CPU を独占して使用する状態になってしまった場合は、Non-yielding scheduler エラー が発生し、60 秒を超えてこの状態が継続された場合には、SQL Server は次のような情報を含むダンプを出力します。
* ******************************************************************************* * * BEGIN STACK DUMP: * 02/19/22 11:35:39 spid 27468 * * Non-yielding Scheduler * * *******************************************************************************
このあたりの動作については、Microsoft が公開しているドキュメントとしては、次のようなドキュメントから確認をすることができます。
- Troubleshooting SQL Server Scheduling and Yielding
- Resource Monitor enters a non-yielding condition on a server running SQL Server
- SQL Server 2019 以降では、Non-yielding のダンプ生成が 60 秒ではなく 120 秒間の CPU 占有に代わり、ダンプ生成のトリガーが変わっているそうです。
古めの情報となりますが、SQL Server 2008 時代のものとしては次のような情報があり、これらの情報は今でも参考となります。
- How It Works: Non-Yielding Resource Monitor
- SQL Server 2008 R2 New Non-Yield Ring Buffer Information
- How To Diagnose and Correct Errors 17883, 17884, 17887, and 17888
Microsoft のサイト以外では、SQL Server 2012 Deep Dive の次のドキュメントが参考になります。
Non-yielding Scheduler で SQL Server から Dump が出力された場合、WinDbg でダンプ解析を行うことができ、ダンプが出力されていた際にスケジューラーを使用していたスレッドを確認できる可能性があります。
ダンプの確認方法については、様々な情報が公開されており、私は次の情報が参考になりました。
- How to analyze Non-Yielding scheduler or Non-yielding IOCP Listener dumps ……
- Demystifying Dumps: Non-Yielding Scheduler
- Debugging a non-yielding scheduler issue
Non-yielding Scheduler についての質問はいくつか上がっており、このエラーに遭遇した方は皆苦労をしているように見えます…。