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 の環境を設定して利用してみた際のメモを。