我正在运行 openstack + kvm,当我在 openstack 上构建 VM 时默认 CPU 拓扑是 vCPU 数量 = 套接字数
例子:
如果我创建具有 32vCPU 的虚拟机,那么我的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
它说我的客户虚拟机有 16 个插槽,每个插槽有 1 个内核和 2 个线程,是的,在现实世界中,主板上几乎不可能有 16 个插槽,所以问题是 Linux 内核是否根据 CPU 拓扑做出调度决策?
只是想了解什么是最佳的 CPU 拓扑对来宾性能有好处
更多插座 vs 更多核心?
编辑
我遵循 OpenStack 性能的所有最佳实践,例如 CPU Pinning、为主机保留 pCPU、HugePage、SRIOV 等。
答案1
不,Linux 不关心套接字。查看有关 CPU 拓扑的 Kernel.org 文档。这段相关段落应该可以阐明情况。
内核不关心物理套接字的概念,因为套接字与软件无关。它是一个机电元件。过去,一个插座总是包含一个封装(见下文),但随着多芯片模块(MCM)的出现,一个插座可以容纳多个封装。
Openstack 默认使套接字数量等于 vCPU 数量。来自OpenStack 维基这段话来了(强调我的):
OpenStack 中的每个虚拟化驱动程序都有自己的方法来定义来宾虚拟机所看到的 CPU 拓扑。 libvirt 驱动程序会将所有 vCPU 公开为单独的套接字,具有 1 个核心且无超线程。
UNIX 操作系统将乐意使用在逻辑 CPU 总数上限内向其公开的任何 CPU 拓扑。也就是说,选择不同的拓扑可能会对性能产生影响。例如,2 个超线程在性能上通常不等同于 2 个内核或插槽,因此操作系统调度程序具有特殊的逻辑来处理任务放置。因此,如果主机有一个具有 2 个内核和 2 个线程的 CPU,并且要运行两个任务,它会尝试将它们放置在不同的内核上,而不是放置在一个内核内的不同线程中。因此,如果向客人展示 4 个插座,操作系统将不会做出最佳调度程序放置决策,以避免竞争受限的线程资源。
因此,Linux 内核文档和 Openstack 文档中的信息是相互冲突的。 Linux 内核文档说,既然我们有了多芯片模块,那么套接字在宏伟的计划中是一个毫无意义的术语。然而,Openstack 似乎指出,UNIX 调度程序更喜欢使用“物理核心”而不是“逻辑核心”来执行任务,并且会遇到将每个核心视为自己的套接字的约束。然而,这无法解释 Openstack 或 VM 的可扩展性。如果 Openstack 在服务器集群上运行,将核心限制为 1 个套接字是否有意义?
那么重要的是你您的虚拟机的虚拟拓扑与您的物理拓扑是否匹配?您的物理拓扑是否会成为“云”或以其他方式位于许多服务器的集群中?