很抱歉发了这么长的帖子，下面是TLDR：对于谷歌云引擎AMD驱动的虚拟机的每一个实例，1vCPU与其他实例相比都会在某种程度上受损。知道如何/为什么吗？
我对谷歌计算引擎提供的各种实例类型进行了性能/价值分析，发现对于我们的工作负载，AMD EPYC Milan供电的n2d类型提供了最佳的性能和价值。然后，我将比较扩展到其他云提供商，你可以在这里看到详细的云提供商性能/价值比较(perl工作负载，以及编译和Geekbench(，在这个过程中，当我试图计算可扩展性等问题时，我可以看到谷歌的AMD EPYC虚拟机发生了一些奇怪的事情：如果你创建了一个2xvCPU，4xvCPU或8xvCPU(没有进一步尝试(AMD Rome(n2d(或AMD Milan(n2d、t2d、c2d(实例，其中1个vCPU与其他vCPU不同，有时性能明显较差(取决于工作负载，甚至差50%以上(。一个例外是2xvCPUt2d或Rome-n2d，在这种情况下，有时你可以让两个vCPU都是"；"慢"；类型
当运行单线程基准测试时，这个问题表现为显著的性能差异，因为vCPU对调度器来说似乎是一样的，所以最终由哪一个来处理负载是一个幸运的问题。但是，如果您使用taskset来设置进程的处理器亲和性，这是非常清楚的。因此，以Geekbench为例，在c2d上；"慢"；我们运行的一个：
taskset 1 ./geekbench5
得到986的单核结果(多核在单个vCPU上运行2个线程，所以类似(。然后尝试在另一个vCPU:上运行
taskset 2 ./geekbench5
看看EPYC米兰实际能做什么，在这种情况下是1266。
如果你看一下基准测试的细分，有几个基准测试似乎没有受到影响，两次运行之间的性能相差不到5%，但也有一些很大的差异，AES-XTS在第二个核心上的速度快了3倍！以下是各种AMD Milan(M(和Rome(R(
| vCPU | n2d-s2(M | ||
|---|---|---|---|
| 快速 | 1251 | >970 | 11266 | <1150>
| 慢速 | 979 | 788 | 986 | 893
让你知道，这是谷歌的官方答案：
我相信这里捕捉到的行为是底层计算引擎资源，谷歌云在其管理程序中使用该资源来运行重要的网络和管理任务。由于该组件，CPU可能无法在所有内核上达到100%。由于组件的相对大小与机器的大小，较小的实例可能会看到这种情况。
目前这种症状的总体立场是，这是基础设施的一部分，并按预期工作。欢迎您选择其他CPU架构类型，或者使用更大的机器类型；这两者中的任何一个都应该弥补系统管理程序资源占用的开销。我仍然将您的发现、复制步骤和评论转发给计算引擎团队以供记录。
这听起来有点合理，直到您开始怀疑为什么它只发生在EPYC实例上，为什么其他提供商的EPYC示例没有发生类似的情况，为什么您的实例的1或2 vCPU受到影响是随机的，以及为什么它只影响小的写入。
所以，对我来说，它不可能完全是"；按预期工作"；，但我认为不值得与他们进一步探讨，正如我所说，这不是什么大问题，当然，除非你碰巧运行了一些非常具体的东西。例如，4k块上的AES加密将仅以受损vCPU上的三分之一速度运行。
更新11/2022：
对我来说，新的n2d和t2d实例似乎已经出现了问题。c2d实例仍然是一个问题，IMHO无论如何都是浪费钱的(一点也不比便宜的类型快(，所以应该避免它们。
更新03/2023:
不仅c2d实例也得到了修复，而且我看到它们最终比n2d获得了更高的时钟速度/性能，因此有理由为它们支付更多的费用。