为什么 GCP 的 AMD EPYC 虚拟机实例似乎有 1 个“有问题的”vCPU？

Question

抱歉这篇文章太长了，这里是 TLDR：对于 Google Cloud Engine AMD 驱动的虚拟机的每个实例，1vCPU 与其他实例相比在某种程度上受到了削弱。知道如何/为什么吗？

我对 Google 计算引擎提供的各种实例类型进行了性能/价值分析，发现对于我们的工作负载，AMD EPYC Milan 驱动的n2d类型提供了最佳的性能和价值。然后我将比较扩展到其他云提供商，您可以在这里看到详细的云提供商性能/价值比较（perl 工作负载，以及编译和 Geekbench 进行良好的衡量），在此过程中，正如我试图计算诸如可扩展性之类的东西，我可以看到 Google 的 AMD EPYC 虚拟机发生了一些奇怪的情况：如果您创建了 2xvCPU、4xvCPU 或 8xvCPU（没有进一步尝试）AMD Rome ( n2d) 或 AMD Milan ( n2d, t2d, c2d) 实例，其中 1 个 vCPU与其他的不一样，有时表现会更差（取决于工作负载，甚至差 50% 以上）。2xvCPUt2d或 Rome-是一个例外n2d，在这种情况下，有时您可以获得两个 vCPU 均为“慢速”类型。

在运行单线程基准测试时，该问题表现为显着的性能差异，因为 vCPU 对于调度程序来说是相同的，因此最终由哪个 vCPU 来处理负载只是运气问题。taskset但如果用设置进程的处理器亲和力的话就很清楚了。因此，以 Geekbench 为例，其中c2dCPU 0 是我们运行的“慢”CPU：

taskset 1 ./geekbench5

得到单核结果 986（多核在单个 vCPU 上运行 2 个线程，因此类似）。然后尝试在另一个 vCPU 上运行：

taskset 2 ./geekbench5

并获得 EPYC Milan 实际可以做的事情，在本例中为 1266。

如果您查看基准细分，会发现多个基准似乎未受影响，两次运行之间的性能偏差均在 5% 以内，但存在一些很大的差异，AES-XTS第二个核心的速度快了 3 倍！下表列出了各种 AMD Milan (M)和 Rome (R)实例上的快 vCPU 与慢 vCPU 结果：

虚拟CPU	n2d-s2 (M)	n2d-s2 (R) A	c2d-s2 (M)	t2d-s2 (M)
快速地	第1251章	970	1266	1150
慢的	第979章	第788章	986	第893章

如果您有一个 8xvCPU 实例，其中只有 1 个核心会出现性能问题，因此对您的影响较小。实际上不存在 #vCPU 出现问题的模式，例如，如果您有一个 8xvCPU 实例，您将尝试任务集的参数 1、2、4、8、16、32、64、128（它需要一个位掩码）以及其中任何一个可以是其中之一。

我尝试了 LMbench 微基准测试，看看内存延迟时间是否有任何差异，以防慢速核心无法访问所有缓存等，但所有 LMbench 内存基准测试对于快速核心和慢速核心都给出了相似的结果，除了来自libc bcopy和 的Memory bzero bandwidth报告显示，第一个 512b - 1k 的带宽是未受影响的 CPU 的两倍多，慢速 CPU 在 4k 标记后慢慢赶上：

fast vCPU           slow vCPU

libc bcopy unaligned
0.000512 74850.98   0.000512 39376.69
0.001024 102429.05  0.001024 56302.91
0.002048 104352.51  0.002048 74090.38
0.004096 108161.33  0.004096 90174.68
0.008192 97034.51   0.008192 85216.90
0.016384 99009.57   0.016384 93743.92
0.032768 54218.61   0.032768 52910.72
0.065536 53300.89   0.065536 49660.89
0.131072 50072.18   0.131072 51533.84

libc bcopy aligned
0.000512 82067.77   0.000512 38346.13
0.001024 103010.95  0.001024 55810.31
0.002048 104568.18  0.002048 72664.92
0.004096 105635.03  0.004096 85124.44
0.008192 91593.23   0.008192 85398.67
0.016384 93007.97   0.016384 91137.35
0.032768 51232.94   0.032768 49939.64
0.065536 49703.80   0.065536 49675.92
0.131072 49760.35   0.131072 49396.37

Memory bzero bandwidth
0.000512 83182.36   0.000512 43423.32
0.001024 95353.76   0.001024 61157.60
0.002048 103437.22  0.002048 76770.77
0.004096 70911.40   0.004096 61986.23
0.008192 84881.63   0.008192 77339.78
0.016384 95343.37   0.016384 87949.77
0.032768 97565.34   0.032768 91436.64
0.065536 93136.11   0.065536 89826.23
0.131072 95790.48   0.131072 90689.07

所有其他基准测试，包括展开的 bcopy 和内存读/写、延迟等都在 vCPU 之间的误差范围内。我不确定这能告诉我们什么，总的来说，我不知道这是如何发生的（某种谷歌管理程序错误？），以及为什么似乎没有人注意到从一开始就非常明显的事情我的基准测试 - 我在谷歌上找不到任何参考资料。而且，当然，您在设计云解决方案时会测试性能，这首先不可能通过任何质量检查。

我看不出我这边可能做错了什么，除了 Debian Bullseye 之外，我确实尝试过其他发行版，并且在 Debian Buster、Ubuntu、CentoOS 上也看到了同样的情况。有关我尝试的更多详细信息，请参阅我前面提到的云性能比较博客文章的最后部分。任何对此有任何见解的人，我都很想知道发生了什么。

Answer 1

只是想让你知道，这是谷歌的官方答案：

我相信这里捕获的行为是 Google Cloud 在其虚拟机管理程序中使用的底层计算引擎资源来运行基本的网络和管理任务。由于此组件的影响，CPU 可能无法在所有内核上达到 100% 的利用率。由于组件尺寸与机器尺寸的相对尺寸，较小的实例可能会更容易看到这种情况。

目前此症状的总体立场是，这是基础设施的一部分并且按预期工作。欢迎您选择其他CPU架构类型，或者使用更大的机器类型；其中任何一个都应该弥补虚拟机管理程序资源占用的开销。我仍然将您的发现、重现步骤和评论转发给 Compute Engine 团队以供记录。

这听起来有点合理，直到您开始想知道为什么它只发生在 EPYC 实例上，为什么其他提供商的 EPYC 实例没有发生类似的情况，为什么您的实例的 1 个或 2 个 vCPU 受到影响是随机的，以及为什么它只影响小写入。

所以，对我来说，它不可能完全“按预期工作”，但我认为不值得与他们进一步追求，正如我所说，这不是一个大问题，除非你碰巧运行一些非常具体的东西。例如，4k 块上的 AES 加密运行速度仅为受感染 vCPU 上速度的 1/3。

更新 11/2022：

n2d对我来说，这个问题似乎已经消失了t2d。这仍然是实例的问题c2d，无论如何，这都是浪费钱（根本不比便宜的类型快），所以应该避免它们。

更新 03/2023：

不仅c2d实例也得到了修复，而且我发现它们最终获得了更高的时钟速度/性能n2d，因此有理由为它们支付更多费用。