对于进程，我为资源 RLIMIT_AS 设置了软限制值 335544320 和硬限制值 1610612736。即使在设置此值之后，进程的地址空间也会上升到最大值 178MB。但是我能够在 /proc/process_number/limits 中看到软限制和硬限制的值正确设置为上述值。
我想知道 RLIMIT_AS 是否在我的操作系统中工作，还想知道如何测试 RLIMIT_AS 功能。
CentOS 5.5(64 位)是我使用的操作系统。
请一些人帮助我解决这个问题。谢谢!
最佳答案
全部setrlimit()限制是上限。一个进程可以使用它需要的资源，只要它保持在软限制之下。来自setrlimit() manual page :
The soft limit is the value that the kernel enforces for the corresponding resource. The hard limit acts as a ceiling for the soft limit: an unprivileged process may only set its soft limit to a value in the range from 0 up to the hard limit, and (irreversibly) lower its hard limit. A privileged process (under Linux: one with the CAP_SYS_RESOURCE capability) may make arbitrary changes to either limit value.
实际上，这意味着硬限制是软限制及其自身的上限。内核仅在进程运行期间强制执行软限制 - 仅当进程尝试更改资源限制时才会检查硬限制。
在您的情况下，您为地址空间指定了 320MB 的上限，而您的进程使用了其中的大约 180MB - 完全在其资源限制之内。如果您希望您的流程增长，您需要在它的代码中。
顺便说一句，资源限制旨在保护系统——而不是调整单个进程的行为。如果一个进程遇到其中一个限制，无论您的故障处理有多好，它是否能够恢复通常都是值得怀疑的。
如果您想通过例如调整进程的内存使用情况分配更多缓冲区以提高性能，您应该执行以下一项或两项操作:
向用户询问适当的值。在我看来，这是应该始终可行的一件事。用户(或系统管理员)应该始终能够控制这些事情，而不是来自您的应用程序的所有猜测。
检查有多少内存可用并尝试猜测合适的分配量。
作为旁注，您可以(并且应该)在编译时处理 32 位与 64 位。像这样的运行时检查很容易失败并浪费 CPU 周期。但是请记住，CPU“位数”与可用内存没有任何直接关系:
32 位系统确实对进程可以使用的内存施加了限制(通常在 1-3 GB 范围内)。这并不意味着这么多内存实际可用。
64 位系统相对较新，通常具有更多物理内存。这并不意味着特定系统实际拥有它或您的流程应该使用它。例如，许多人构建了配备 1GB RAM 的 64 位家庭文件服务器以降低成本。我知道很多人会因为一个随机过程仅仅因为它只考虑自己而强制他们的 DBMS 交换而感到恼火。
关于c - RLIMIT_AS 无法将其软限制设置为特定值，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5202463/