openstack + kvmを実行していてopenstackからVMを構築するとき、デフォルトのCPUトポロジはvCPU数=ソケット数です。
例:
32vCPUでVMを作成すると、私のlscpu外観は次のようになります。
# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 32
On-line CPU(s) list: 0-31
Thread(s) per core: 2
Core(s) per socket: 1
Socket(s): 16
私のゲストVMには、ソケットごとに1つのコアと2つのスレッドを持つ16のソケットがあるとします。はい、現実の世界ではマザーボードに16個のソケットを持つことはほとんど不可能なので、問題はLinuxカーネルです。 CPUトポロジに基づいてスケジューリングを決定していますか？
ゲストのパフォーマンスに最適なCPUトポロジが何であるかを理解しようとしています。
より多くのソケットとより多くのコア？
編集する
私は、CPU固定、ホスト用のpCPU予約、HugePage、SRIOVなどのOpenStackパフォーマンスに関するすべてのベストプラクティスに従います。
ベストアンサー1
いいえ、Linuxはソケットに興味がありません。確認するCPU トポロジに関する Kernel.org ドキュメント。この関連詩を通して状況が明確になるはずです。
ソケットはソフトウェアとは何の関係もないので、カーネルは物理ソケットの概念を気にしません。電気機械部品です。以前は、ソケットには常に単一のパッケージ（以下を参照）が含まれていましたが、マルチチップモジュール（MCM）の出現により、ソケットは複数のパッケージを収容できます。
OpenStack はデフォルトでソケット数を vCPU 数と同じにします。 ~からオープンスタック Wikiここにこの節があります（強調）：
OpenStackの各仮想化ドライバには、ゲスト仮想マシンに表示されるCPUトポロジを定義する独自の方法があります。 libvirtドライバは、すべてのvCPUをハイパースレッディングなしで1つのコアを持つ別々のソケットとして公開します。
UNIXオペレーティングシステムは、最大総論理CPU数まで公開されているすべてのCPUトポロジを使用します。つまり、別のトポロジを選択するとパフォーマンスに影響を与える可能性があります。たとえば、2つのハイパースレッドは通常、2つのコアまたはソケットと同じパフォーマンスを持っていないため、オペレーティングシステムスケジューラにはタスク配置を処理する特別なロジックがあります。したがって、ホストに2つのコアと2つのスレッドを持つCPUがあり、2つのタスクを実行したい場合は、あるコア内の別のスレッドに配置するのではなく、別のコアに配置しようとします。したがって、4つのソケットがゲストに表示された場合オペレーティング・システムは、限られたスレッド・リソースに対する競合を避けるために最適なスケジューラー・デプロイメントの決定を行いません。。
そのため、LinuxカーネルのドキュメントとOpenstackのドキュメントの情報が競合します。 Linuxカーネルのドキュメントによると、マルチチップモジュールがあるので、ソケットは全体的なスキームで意味のない用語です。しかし、OpenStackは、UNIXスケジューラがタスクを実行するために「論理コア」ではなく「物理コア」を使用することを好み、各コアを独自のソケットで処理する必要がある制約に直面することを指摘しているようです。ただし、これはOpenStackまたはVMのスケーラビリティを説明しません。 OpenStackがサーバークラスタで実行されている場合は、コアを1つのソケットに制限するのが合理的ですか？
それでは何が重要ですか？あなた仮想マシンの仮想トポロジは物理トポロジと一致していますか？物理トポロジは「クラウド」ですか、それとも複数のサーバーのクラスタにありますか？