ESXiでマルチコアゲストを使用した物理ホスト待機を予測/測定する方法
ESXiでN個の仮想コアを持つゲストがいる場合、ハイパーバイザーは、ホスト上の合計N個の論理プロセッサが同時に使用可能になるのを待ってから、ゲストからハードウェアに作業を委任すると聞きました。したがって、処理サイクルが本当に必要な場合を除いて、ゲストをXコアずつ増やすことを慎重に検討する必要があります。これは、Xに比例して待機時間が増加し、vcpusを追加することによる利益がこの増加した遅延のコスト。
極端な例では、ESXiホストhAとhBのハードウェアと構成が同じで、それぞれに1つのゲスト（それぞれgAとgB）があり、gAに1つの仮想CPUがあり、gBに2つあるという事実を除いて、ゲストは同じであるとします。両方のホストに同じ（並列化できない）ワークロードを配置した場合、gAはタスクを「より速く」競合する必要があります。
- このproc待機遅延は本当ですか？ VMWareのドキュメントで確認できますか？
- それが現実である（そして提供されたドキュメントからは明らかでない）場合、ゲストvcpuの増加の予測される影響を事前に測定する方程式はありますか？遅延がすでにどのような現実世界の影響を及ぼしているかを測定するためのツールはありますか？
-関連性があるとすれば、この質問のきっかけとなる現実の問題は、4つのコアを備えたMS SQL Server 2014があり、日中平均60％の容量で実行され、定期的に100％に急上昇し、社内で議論が行われていることです。ゲストを6コアまたは8コアに増やして、発生しているパフォーマンスの問題を軽減するのが賢明かどうかについて。ホストには（モデルはわかりませんが、仕様のみ）2.6GHzのデュアルソケットIntel hexcore、ハイパースレッディングがあります。つまり、ホストあたり24個の論理コアがあります。
ハイパースレッディングは、数パーセントのブーストを得るためにコアの数について嘘をついています。 24コアではなく、12コアですが、ハイパースレッディングを使用するゲストにこれらの12コアを完全に使用する方が少し良いと思います。
ゲストがノードのサイズを超えると、リモートCPUまたはRAMへのアクセス時にNUMA効果が発生します。これらの16進コアソケットの場合、間違いなくvCPU 8によるものです。これらは、ハイパーバイザーのない物理サーバー上のオペレーティングシステムにも適用されます。 ESXiとMSSQLがはるかに大きく拡張されていることを考えると、おそらく管理可能です。収穫逓減があることを知っておいてください。
Strictco-scheduling、ここでVMのすべてのvCPUは、スケジューリングの偏りがある場合に停止されます、 ESX 2以降は使用されていません 。緩和された共同スケジューリングは、vCPUごとの決定に近いものです。CPUが他のCPUよりも進歩しているかどうかは、 esxtopの％CSTP で測定できます。
スケジューラーが何であれ、最大のスループットと最小のレイテンシーのために、vCPUをオーバーサブスクライブしないでください。これらのデュアルヘキサコアは、合計12個のvCPUをゲストに提供します。ゲスト専用のCPUが効果的にあれば、アイドル状態のCPUを待つ必要はありません。
VMwareに関する不十分なアドバイスや、機能しなくなったベストプラクティスがたくさんあります。
VMwareのWebサイトでさえ、SEOが不十分なために古いソリューションを宣伝しています。
ただし、これを評価するrightの方法は、 vSphere Realize Operations Manager（vROPs） のようなツールを使用してサイズの推奨事項を取得することです。あなたの実際の活動に基づいています。
それ以外の場合は、影響を増やしてテストします。 5 vCPUに移動し、測定します。次に、6つのvCPU ...など。
また、リソース割り当てをよりよく理解するために、テクニカルディープダイブの本の1つを読んでください： https://www.Amazon.com/gp/product/1540873064
例：
