SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
先日投稿した SQL Server 2022 で Non-yielding Scheduler 発生時の出力内容が追加されていました は SQL Server 2022 向けの情報となり、投稿時点の最新バージョンの SQL Server を使用することで、ERRORLOG から g_copiedStackInfo のコンテキストを取得し、スケジューラーを解放しないスレッドのスタックを確認することができることを確認しました。
それ以外のバージョンでは、ダンプが出力されたタイミングでしか確認できないとなると、発生時の初回の情報しか確認でいないことになり、SQL Server のサービスを連続稼働している最中のエラーの原因特定が困難になってしまいます。
これを解消することができないか、考えていたところ「nonyield_copiedstack_ring_buffer_recorded」という拡張イベントを見つけることができました。
現在、SQL Server の物理の検証環境としては NUC9VXQNX を使用しています。
SQL Server は NUMA アーキテクチャ を意識したソフトウェアとなっており、NUMA ノード単位にスレッドが作成される / NUMA ノード単位の情報取得が行われるものがあり、一部の検証では複数の NUMA ノードがある環境が欲しくなることがあります。
Hyper-V の仮想マシンであれば、17コア以上の環境であれば仮想マシン上では複数ソケットになるのですが、現在 NUC でこれを満たせるのは、NUC13 エクストリームキットぐらいになると思うのですが、残念ながら手元にはありません…。
Azure の仮想マシンで実行することで利用することはできるのですが、試行錯誤して検証を実施しているとコストもそれなりにかかってくるかと思います。
ということで、冒頭に記載した Gen9 の NUC (Xeon モデル) を使用して、Fake NUMA の環境を設定して利用してみた際のメモを。
SQL Server でスレッドが CPU を解放せずに占有し続けた状態となる Non-yielding Scheduler となった場合、SQL Server のプロセスのダンプが出力されます。
出力されたダンプについては、Non-yielding IOCP Listener, Non-yielding Scheduler and non-yielding resource monitor known issues and fixes で解説されている内容を基に解析を行うことになりますが、SQL Server 2022 では解析のための情報が追加されているようです。
SQL Nexus でレポートを作成する際に、一部の内容 (例: Perfmon Summary の Click here to view more CPU metrics) を表示する際に、次のエラーが発生することがあります。
System.Data.SqlClient.SqlException (0x80131904): 文字列から日付と時刻、またはそのいずれかへの変換中に、変換が失敗しました。 (英語だと Conversion failed when converting date and/or time from character string.)
SOS_WORK_DISPATCHER については、What is the SOS_WORK_DISPATCHER Wait Type? で解説が行われていますが、SOS_WORKER との比較を把握しておきたかったのでメモとして。