SQL ServerをホストするVMの専用リソース
私の理解では、VMを使用することの大きな利点の1つは、ホスト上の仮想マシン間でリソースを共有できることです。したがって、120個のCPUを搭載したホストで5つのVMをそれはそれぞれ32 CPUを備えています。追加のCPUはVM間で「共有」され、ホストは必要に応じて動的にCPUを割り当てます。メモリについても同様です。
これはSQL Serverを格納するVMにとっては大きな問題だと理解しましたが、VM管理者が同意しません。何らかの形で証拠や文書を持っている人はいますか？
重要かどうかはわかりませんが、VMWareを使用しています。
「CPUをオーバーコミットしても大丈夫ですか？」
CPUの消費に関連するパフォーマンスのボトルネックが発生し始めるまでは問題ありません。同じ答えがネットワークのオーバーコミットメントにも当てはまります。ホストに5つの別々の10 Gbイーサネットカードを配置して、VMごとに1つのカードを割り当てるのとは異なります。仮想化はすべてオーバーコミットメントに関するものであり、リソースの可用性とリソース要件の間の境界線をたどります。
ただし、SQL Serverは提示されたメモリを積極的に使用するので、一般的に言って、メモリをオーバーコミットすることは望ましくありません。 VMのページをホストのディスクに移動させるのではなく、VMごとの分析を行って、より少ないメモリで稼働できるVMを特定し、最初はより少ないメモリでそれらを構成する方がよいでしょう。
一部のリソースを動的に割り当てることで発生する問題は、予測できないパフォーマンスにつながることです。レポートクエリxには昨日32個のCPUがあり、4分で実行されましたが、今日は24個しかなく、かなり時間がかかりました。ゲストが他のコアが利用可能になるのを待つときの待ち時間も確認できます。
Jonathan KehayiasはここでCPUとメモリのオーバーサブスクライブについていくつかの実際的な警告を出します（そして率直に言って、私は彼の経験とアドバイスを典型的なVM管理者よりも信頼していますが、彼らには不快ではありませんが、彼は組み合わせによるより直接的な経験）：
私の理解では、ある程度のCPUオーバーコミットメントは完全に問題ないかもしれませんが、それはすべてのゲストのワークロード要件に完全に依存しています。 VM情報の詳細については、David Kleeのブログをご覧ください。具体的には http://www.davidklee.net/articles/sql-server-articles/cpu-overcommitment-and -its-impact-on-sql-server-performance-on-vmware / CPUオーバーコミットメントの説明とSQL Serverへの影響。
メモリのオーバーコミットメントは別の動物であり、一般的に、VMホストがSQL Serverを実行している場合、ホストはメモリでオーバーコミットされるべきではありません。もう一度、David Kleeを参照として使用します。 http://www.davidklee.net/2013/11/04/lock-pages-in-memory-in-sql-server-on-vmware-why-or-why-not/ 場所メモリーのオーバーコミットメントの影響について説明します。
お役に立てれば。