AWS在2026年8月26日宣布，Mountpoint for Amazon S3新增内存使用控制。用户可以让Mountpoint根据运行环境自动计算安全目标，也可以通过参数手动指定内存预算，减少它与机器学习训练、分析程序等高内存业务争抢资源。
Mountpoint会把S3存储桶挂载成Linux文件系统，应用可以通过常见文件操作访问对象。为了提升读写吞吐，它会在内存中预取数据并缓存待上传分片；旧版本的内存占用可能随访问模式扩大，在小内存云服务器或严格限制资源的容器中容易带来稳定性问题。
旧机制可能逐步挤压业务可用内存
读取大对象时，Mountpoint会提前获取后续数据，减少应用等待网络请求的时间；写入对象时，它还需要保留分片缓冲区并并行上传。这些策略可以换取吞吐，但也会持续占用内存。
当同一台EC2实例同时运行模型训练、数据处理或数据库任务时，业务进程与Mountpoint使用的是同一份内存预算。访问并发和文件数量上升后，Mountpoint占用扩大可能触发系统换页、容器被OOM终止，或者让关键程序得不到足够缓存。
这次更新解决的是资源边界不可控的问题。用户可以先给业务进程预留明确空间，再让Mountpoint在剩余预算内调整缓存与并发策略。
memory-target提供目标而不是绝对硬上限
新版本加入--memory-target参数，以MiB为单位设置Mountpoint总内存使用目标，允许的最低值为512MiB。没有手动指定时，默认目标为系统总内存或cgroup限制内存的95%。
官方文档明确说明，memory target不是保证永远不会越过的硬限制。Mountpoint会以该数值管理数据缓冲区，并额外为元数据、文件句柄等内部开销保留max(128 MiB, memory_target / 8)的空间。
内存压力升高时，Mountpoint会放慢I/O、回收不再需要的缓冲区并减少预取。这样可以降低被OOM终止的概率，但业务可能看到读写吞吐下降，因此不能把目标设置得过低后仍期待原来的并发性能。
EKS容器可以自动识别分配的内存预算
Mountpoint能够读取cgroup内存限制。在Amazon EKS中运行时，它可以识别容器实际分配到的内存，而不是把整台工作节点的物理内存都当成可用空间。
这一点对共享节点尤其重要。同一节点可能同时运行训练任务、日志组件和Mountpoint Pod；只按宿主机容量判断，会让单个容器在压力出现前使用过多缓冲。新的默认行为可以让内存策略更贴近Pod资源限制。
自动识别仍不能代替资源规划。部署文件需要给Mountpoint容器设置合理的request和limit，并为应用峰值、文件句柄、元数据以及系统守护进程留出余量，避免所有组件都按照接近上限配置。
内存目标会直接影响并发写文件数量
每个打开等待写入的文件都要保留一个分片大小的缓冲区，因此内存目标与--write-part-size共同决定可同时打开多少个写文件。达到上限后，新的写入打开操作会返回ENOMEM，直到已有文件关闭。
按官方默认8MiB分片计算，512MiB内存目标允许同时打开约47个写文件，4GiB目标则约为447个。降低分片大小可以提高并发文件上限，但也可能增加S3请求数量并改变吞吐表现。
限制内存不是没有代价的免费优化。大量小文件写入、模型检查点保存和并行分析任务上线前，应同时测试峰值内存、打开文件数、请求次数、吞吐和延迟，不能只观察进程是否超出目标。
升级后需要重新验证吞吐与告警阈值
该能力已经面向所有AWS区域开放，用户需要升级到最新Mountpoint版本。启动日志会记录实际内存目标和最大并发写文件数量，运维团队可以据此确认参数是否按预期生效。
测试时应覆盖顺序读取、大文件写入、多文件并发以及内存压力场景，并观察业务进程RSS、容器OOM事件、Mountpoint错误日志、S3请求量和端到端处理时间。
对内存紧张的VPS或容器来说，先设置保守目标再逐步提高更容易找到平衡点。只有业务吞吐、Mountpoint稳定性和系统剩余内存同时达标，这项内存控制才算真正完成配置。
