我遇到了严重的性能问题，更详细的解释请见这和那其他问题。从我迄今为止的测试来看，这与分配给虚拟机的内存量有直接关系：问题发生在 48 GiB 的 RAM 上，而只有 6 GiB 甚至 24 GiB 的 RAM 时则不会出现问题。此外，启用largepages虚拟机的设置似乎也有积极的影响，尽管它不能完全解决问题。它似乎只是稍后才会发生。
这很有趣，因为这个设置似乎默认没有启用Linux，文档只说了约 5% 的改进，并不是说在某些 RAM 大小下获得良好性能的必要条件，此外还存在一些largepages情况被 VirtualBox 忽略共。
00:00:42.866663 PGMR3PhysAllocateLargePage：分配大页面花费的时间太长（最后一次尝试 103 毫秒；超时次数 11）；禁用
https://www.virtualbox.org/attachment/ticket/16518/VBox_16518_5112.log#L1154
因此，目前在我看来，似乎不清楚在哪些情况下largepagesVirtualBox 不仅建议而且需要正常运行。为了区分这一点，需要知道过去虚拟机使用的 RAM 大小是否正常，哪些largepages不是，因为性能问题，比如我所看到的那些，如果有的话。
答案1
我看到的行为非常符合以下情况Linux 内核讨论的问题：
内存管理性能倒退的决斗
尽管它主要谈论的是交换，补丁修复者这也只会导致 CPU 负载过重：
vfio 是一个很好的测试，因为通过固定所有内存，它可以避免交换，并且回收只浪费 CPU，基于 memhog 的测试会产生交换风暴，并且可能会显示更大的 stddev。
有一件事我不确定，那就是影响，Transparent Huge Pages因为虽然在我的系统中默认启用了它们，但 VirtualBox 似乎并不使用它们，而且它们似乎是针对操作系统设置而选择的：
$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
$ cat /sys/kernel/mm/transparent_hugepage/defrag
always defer defer+madvise [madvise] never
其余一切都与我看到的完全吻合，所以largepages可能真的只是稍微改善了一点，但对于运行具有大量内存的虚拟机来说，这根本不是必需的。目前看来，问题在于 Linux 内核本身的一个“错误”。