SQL ServerをホストするVMの専用リソース

私の理解では、VMを使用する大きな利点の1つは、ホスト上の仮想マシン間でリソースを共有できることです。したがって、120個のCPUを搭載したホストに、それぞれに32個のCPUを搭載した5つのVMを配置できます。追加のCPUはVM間で「共有」され、ホストは必要に応じて動的にCPUを割り当てます。メモリについても同じです。

また、これはSQL Serverを格納するVMにとっては大きな問題であると理解していましたが、私のVM管理者は同意しません。誰かが何らかの形で証拠や文書を持っていますか？

問題かどうかはわかりませんが、VMWareを使用しています。

「CPUをオーバーコミットしても大丈夫ですか？」

CPU消費に関連するパフォーマンスのボトルネックが発生し始めるまでは問題ありません。同じ答えがネットワークのオーバーコミットメントにも当てはまります。ホストに5つの別々の10Gbイーサネットカードを配置し、VMごとに1つのカードを割り当てるのとは異なります。仮想化はすべてオーバーコミットメントに関するものであり、リソースの可用性とリソース要件の間の境界線を歩いています。

ただし、SQL Serverは提示されたメモリを積極的に使用するので、一般的に言って、メモリをオーバーコミットすることは望ましくありません。VMのページをホストのディスクに移動させるのではなく、VMごとの分析を行って、より少ないメモリでどのVMが稼働できるかを把握し、最初に少ないメモリで構成することをお勧めします。

一部のリソースを動的に割り当てることで発生する問題は、予測できないパフォーマンスにつながることです。レポートクエリxは、昨日は32個のCPUを使用でき、4分で実行されましたが、今日は24個しかなく、かなり時間がかかりました。ゲストが他のコアが利用可能になるのを待つときの待ち時間も確認できます。

Jonathan Kehayiasは、ここでCPUとメモリのオーバーサブスクライブについていくつかの実際的な警告を出します（そして、率直に言って、彼の経験とアドバイスは、通常のVM管理者よりも信頼できます。

• 偶発的なDBA（30日目の5）：仮想化に関する考慮事項

私の理解では、ある程度のCPUオーバーコミットは完全に問題ないかもしれませんが、それはすべてのゲストのワークロード要件に完全に依存しています。多くの優れたVM情報については、David Kleeのブログをチェックしてください。CPUオーバーコミットメントの説明とその影響については、具体的にはhttp://www.davidklee.net/articles/sql-server-articles/cpu-overcommitment-and-its-impact-on-sql-server-performance-on-vmware/を参照してください。 SQL Server。

メモリのオーバーコミットは別の動物であり、一般に、SQL Serverを実行している場合、VMホストはメモリでオーバーコミットされるべきではありません。もう一度、David Kleeをリファレンスとして使用します。http://www.davidklee.net/2013/11/04/lock-pages-in-memory-in-sql-server-on-vmware-why-or-why-not/ここで、メモリの影響を説明しています-コミットメント。

お役に立てれば。