web-dev-qa-db-ja.com

SQL ServerのVMでCPUを共有することは正常ですか？

私たちのITでは、SQL ServerをVM他のVMを含む大きなVMWareボックスに設定しています。CPUは共有として設定されています。その結果、複数のCPUを必要とする可能性のあるクエリは、30倍長くかかります。単一のCPUに制限した場合よりも。例：

SELECT TOP 2000 lwa.Message INTO #foo
FROM dbo.LogWidgetsAPI lwa (NOLOCK)
ORDER BY lwa.TimeStamp

対

SELECT TOP 2000 lwa.Message INTO #foo
FROM dbo.LogWidgetsAPI lwa (NOLOCK)
ORDER BY lwa.TimeStamp
OPTION (MAXDOP 1)  ------------- Force it to run on a single CPU

最初の例は並列処理を使用しており、約30秒ほどかかります。 2つ目は、単一のCPUの使用を強制し、20ミリ秒かかります。

注：シングルCPUクエリを実行した後、マルチCPUクエリの実行に戻り、タイミングと計画は同じです-したがって、問題は「コールド」に関連するとは思わないキャッシュ」対「ウォームキャッシュ」

したがって、私の理論では、最初のクエリは複数のCPUを使用するため、問題のすべてのCPUがアイドルになるまで待機する必要があるため、待機するだけです。

だから私の質問。 SQL Server VMには専用CPUが必要ですか、それとも共有CPUが通常ですか？

これが、並列処理を使用する 計画 です。これが 計画 で、単一のCPUを強制します。

sql-serversql-server-2016parallelismvmwarevirtualisation
3
AngryHacker

SQL ServerのVMでCPUを共有することは正常ですか？

ええ、それはかなり一般的です。多くの場合、VMを使用して、多数のSQL Server（特に、極端なパフォーマンス要件を持たないもの）を1つのホストに統合します。 SQL Serverはホストレベルでライセンスを取得できるため、これによりライセンスコストを節約できます。

それは良い考えですか？つまり、どのようにオーバーサブスクライブされたかVMであるか）、およびCPUがワークロードにどれだけ集中しているかに大きく依存します。

2つの実行プランのスクリーンショットを見ると、並列処理を除いて、基本的には基本的にです。並列プランの1つの問題のある領域は、「トップ」オペレーターが住んでいるシリアルゾーンです。

screenshot of the serial zone in the parallel plan

すべての行を1つのスレッドにまとめ、それらを並列挿入のために再配布することに関連するオーバーヘッドがいくつかあります。ただし、オーバーヘッドが30秒になるとは思いません。

したがって、私の理論では、最初のクエリは複数のCPUを使用するため、問題のすべてのCPUがアイドルになるまで待機する必要があるため、待機するだけです。

いいえ、それはSQL Serverで並列処理が機能する方法ではありません。プランの右上にあるクラスター化インデックスをスキャンしているスレッドは、さまざまなCPUのビジー度に応じて、非常に不均一なレベルの作業を実行できます。

SQL Serverのこのインスタンスが非常にビジーで、使用可能なすべてのスレッドが他のクエリに使用されている場合、並列クエリはTHREADPOOLで待機している可能性があります。これは私を次のポイントに導きます：

並列クエリは、おそらくいくつかのリソースで待機しています。まず、SSMSの実行プランの「WaitStats」部分を見てみましょう。

screenshot of waitstats node in SSMS execution plan

これは、プランの左端の演算子の[プロパティ]ウィンドウに表示されます。一例として、この場合のSOS_SCHEDULER_YIELDの値が非常に高い場合、このSQL ServerインスタンスがホストのCPUをオンにしていない可能性があります。 Jonathan Kehayiasは、このトピックに関して非常に優れた投稿をしています。

SOS_SCHEDULER_YIELDに対するCPU準備完了の影響

2つのクエリで、経過時間とCPU時間の比率を比較することもできます。これらの数値は同じプロパティウィンドウにあります。

screenshot of time stats node in SSMS execution plan

2つのクエリ間で比率が大幅に異なる場合は、並列クエリがリソースを待機していることを示しています。

ホスト/仮想化にアクセスできる場合は、そこで直接統計を調べて、ゲストがCPUでスケジュールされるのを長時間待っているかどうかを確認できます。ジョナサンは、VMWareに固有の、これに関する別の投稿をここに掲載しています。 VMwareでのCPU準備時間とその実際の意味の解釈方法

3
Josh Darnell

元々コメントに残された回答内容

いいえ、VMWareはSQL Serverを認識しないため、Windowsのみを認識します。これは、CPUをVM内のプロセスのレベルではなく、VMのレベルでスケジュールします。 – Gaius

コアによってSQLのライセンスを取得しています...なぜSQL以外のものと共有しているのですか？はい、CPUのオーバーサブスクライブは仮想化の通常の方法ですが、SQLの場合は通常行われません。 – Jonathan Fite

2つのクエリの論理IOを比較します。経過時間と同じ比率であれば、ハイパーバイザーに問題はありません。 VMゲストでスレッドをスケジュールすることができますが、ホストで待機することができるため、ここではCPU時間を比較することはできません。– David Browne-Microsoft

Vm Hostでcpu ready statistics を監視して、その質問にオーバーサブスクリプションが発生しているかどうかを確認する必要があります。

VMwareと共有CPUについて覚えておくべきことの1つは、CPUに対して命令を実行する前に、VMに割り当てられているVCPUの数を取得する必要があることです。

つまり、vmに8つのvcpusが割り当てられているが、処理の指示があるときに4つしか使用できない場合、処理する前に、すべての8を取得するまで待機する必要があります。

オーバーサブスクライブされたホストでは、VMがCPUレディメトリックでコアがオンになるのを待機している頻度を確認できます。通常5％を超える値を持つメトリックは、CPU制約があることを示す強力な指標です。 – Aaron

2
user126897