`ulimit -m` / RLIMIT_RSS 不起作用背后的历史是什么？

Question

根据man setrlimit（这也是man ulimit我所指出的），

限制RSS

指定进程驻留集（驻留在 RAM 中的虚拟页面数）的限制（以字节为单位）。此限制仅在 Linux 2.4.x、x < 30 中有效，并且仅影响指定 MADV_WILLNEED 的 madvise(2) 调用。

因此，似乎ulimit（和setrlimit）只能限制进程使用的虚拟内存。另一方面，像这个断言（看起来是正确的）虚拟内存是一个几乎毫无意义的统计数据，特别是在 Java 应用程序中，通常请求的虚拟内存远远超过将要使用的内存。

所以我想知道，我能对系统施加的限制和实际有意义的数字之间似乎存在脱节，这是怎么回事。如果可以回答的话，为什么会出现这种情况？

Answer 1

RSS 是一个实现细节。程序可以控制的唯一资源是 RLIMIT_AS 和 RLIMIT_DATA。Unix 实现可以修复 RSS == VMA 始终（提交所有请求的内存），并且只要计算机不够强大，无法准备好浪费内存，所有 Java 虚拟机就会在加载时崩溃。

因此，引用的线程上的评论仅代表该人的观点，与 Unix 的架构不符。

要在 Linux 上尝试此行为：

1. 使用 mem=4G 参数启动内核（或尝试使用不同的值）
2. sudo sysctl vm.overcommit_memory=2
3. 运行 Chromium 或某些试图保留超过 4 GB 的程序（崩溃）