虽然我读到过微型实例有时可能会有些超卖，但人们普遍认为 AWS 不会超卖 RAM 或 CPU。尽管如此，RAM 膨胀是 XEN 广泛使用的功能，我注意到内核驱动程序和膨胀守护程序正在 EC2 机器上运行，那么是什么阻止亚马逊通过膨胀 RAM 来优化其资源使用率呢？
我想进一步调查这个问题，因为我遇到过这样一种情况：8GB EC2 Unbuntu 无法分配 RAM 来重新启动 Tomcat，尽管根据 free 和 top 有将近 1.8 GB 的可用内存，并且磁盘缓存中大约有 4GB 可回收。我把所有进程的 RSS 加起来，发现 free 值少了大约 4GB，这或多或少与磁盘缓存大小相匹配。然而，系统一直对命令行中堆有限的 Tomcat 应用程序说 OOM。
因此，要么是 AWS 正在有效膨胀，要么是由于某种原因无法回收磁盘缓存（可能速度不够快，无法避免 OOM？）。也许交换会有所帮助，但 AWS 中存在有关交换的某种宗教战争，而我不是管理员所以我对此无能为力。
所以回到最初的问题：如果 XEN 膨胀驱动程序已加载且守护进程正在运行，那么是什么阻止了 Amazom 膨胀？在我看来，如果 Amazon 不通过膨胀来弥补资源分配的瞬时峰值，那将是愚蠢的。此外，这是 XEN 的一个基本功能，我认为那些坚持认为 Amazon 不使用它的人从未设置或运行过自己的 XEN 环境。
答案1
没有 Amazon EC2 实例类型会超额订购 RAM。只有T系列实例规格超额认购 CPU，见第 14 页https://www.slideshare.net/AmazonWebServices/deep-dive-on-amazon-ec2
这内存过量使用 Xen 文档在功能说明中，“内存过量使用可能会对性能产生一些影响，并且在某些环境中可能无法使用”。Amazon EC2 通过不实施它来避免这些问题和相关的客户影响。另一个原因是实例隔离，如第 4 页所述AWS 安全性概述 - 计算服务白皮书在将内存交给客户机之前，内存会被清理。想想在膨胀场景中这样做对性能的影响。