仮想化されたSQL Serverが100％のCPUと0のアクティブメモリにヒット
最近、サーバーの1つで奇妙なクラッシュが発生しました。原因はわかっていますが、SQL Serverが応答した理由がわかりません。
SQL Server 2016
これが起こったことです：
金曜日：コンパイルされたクエリに与える影響を確認せずに、MAXDOPを4から2に変更しました。
土曜日の朝：サーバーは午前2時から徐々にCPUを使用し始め、午前5時に100％になり、アクティブRAMがすぐに44GBから500MBに低下します（何ですか？！？！））。サーバーは再起動されます。すべてうまくいきます。
月曜日の朝：夜間のバッチジョブの1つが開始される1:05 AMに、サーバーは100％CPUに達し、1：15 AMまでにアクティブメモリを500 MBにドロップします。
毎晩のバッチ処理の一部として、このサーバー上で毎朝実行されるかなりの数の大きなクエリがあります。クエリストアを見ると、金曜日にMDOPに変更される前に、すべて4コア用にコンパイルされたことがわかります。
したがって、4つのコアを使用していたすべての大規模なクエリは2つに再コンパイルする必要があり、そのため、このサーバーで最もビジーなタイムフレームの1つですべてのクエリが大幅に遅くなりました。これがサーバーのパフォーマンスにどのように大きな影響を与えるかは理解していますが、サーバーが完全に応答しなくなり、アクティブなメモリがほとんどなくなった理由はわかりません。
誰かがこの種の行動の経験がありますか？
David Kleeによるこの興味深い投稿をチェックしてください： SQL Server VMのVMメモリカウンターが嘘をつく
特に、この引用はあなたの状況に非常に関連しています：
SQL ServerはメモリをワーキングセットI/Oバッファーとして使用し、SQL Serverバッファープール内のメモリブロックは、最も一般的には読み取りキャッシュとして使用されます。繰り返し読み取られるメモリブロックは、そのブロックが最後のサンプル間隔（通常は20秒）で読み取られたり書き込まれたりした場合にのみ、アクティブカウンターに表示されます。したがって、VMに割り当てられたメモリの適切な量（または多すぎますが、話は異なります）があるSQL Serverは、メモリ内の一般的にアクセスされるデータのほとんどを持ちますが、これらのブロックはVMアクティブなメモリカウンタは、非常に低いアクティブな値を示しますが、このSQL Serverは実際には非常にビジーである可能性があります。
これは最初の問題を説明します（「アクティブ」メモリに関連）。本質的に、あなたが見ていた測定基準は信頼できないので、それは状況についての実質の多くを私たちに伝えません。
応答がないことに関連する他の質問は、停止時または再コンパイルされた実行プランの詳細から wait stats を確認せずに特定することは困難です。
私が推測するつもりなら、もっともらしい理論はそれかもしれない：
- クエリがMAXDOP 2（4ではなく）で実行されるようになると、完了までにかなり時間がかかる
- クエリが以前と同じ速度でサーバーに到着する
- そのため、一度により多くのクエリが実行されます（完了までに時間がかかるため）。
- 実行中の同時クエリが多すぎるため、サーバーでスレッド不足（ threadpool waits ）が発生し始めます
- クエリがメモリ許可を必要とする場合、メモリのキューイングを開始することもできます（ resource_semaphore waits ）
これらすべてが組み合わさって、サーバーが応答していないように見えます。また、メモリページへのアクセスが少なくなる可能性があるため（すべてがCPUリソースで待機しているため）、VMの "アクティブメモリ"が低下する可能性もあります。
CPU使用率がinside VMから測定されている場合は、仮想コアでスレッドがスケジュールされている時間の割合を測定しています。ただし、ハイパーバイザーホストの物理コアで常にスケジュールされるという意味ではありません。
物理サーバー、または専用コアを備えたVMでは、CPU時間の1秒ごとにほぼ同じ量の作業（リタイアされるCPU命令の数とメモリ読み取りの数）が実行されます。ただし、ハイパーバイザーのCPUが他のVMでビジー状態の場合、ゲストのCPU時間の2分の1は、通常よりも有用でない作業を実行する可能性があります。