所有setrlimit()限制都是上限。只要进程保持在软限制之下，它就可以根据需要使用尽可能多的资源。从setrlimit()手册页：
软限制是内核为相应资源强制执行的值。硬限制充当软限制的上限：非特权进程只能将其软限制设置为从 0 到硬限制范围内的值，并且（不可逆转地）降低其硬限制。特权进程（在 Linux 下：具有 CAP_SYS_RESOURCE 功能的进程）可以对任一限制值进行任意更改。
实际上，这意味着硬限制是上限软限制和自身两者。内核仅在进程运行期间强制执行软限制 - 只有当进程尝试更改资源限制时才会检查硬限制。
在您的情况下，您为地址空间指定了 320MB 的上限，并且您的进程使用了其中的大约 180MB - 完全在其资源限制内。如果您希望您的流程增长，您需要在其代码中做到这一点。
顺便说一句，资源限制旨在保护系统 - 而不是调整单个进程的行为。如果一个进程遇到这些限制之一，无论您的故障处理有多好，它是否能够恢复通常都是值得怀疑的。
如果您想通过例如分配更多缓冲区来提高性能来调整进程的内存使用，您应该执行以下一项或两项操作：
向用户询问适当的值。在我看来，这是应该始终可能的一件事。用户（或系统管理员）应该始终能够控制这些事情，而忽略您的应用程序中的任何和所有猜测。
检查有多少内存可用并尝试猜测要分配的内存量。
作为旁注，您可以（并且应该）在编译时处理 32 位和 64 位。类似这样的运行时检查很容易失败并浪费 CPU 周期。但是请记住，CPU“位数”与可用内存没有任何直接关系：
32 位系统确实对进程可以使用的内存施加了限制（通常在 1-3 GB 范围内）。这并不意味着实际上有这么多内存可用。
64 位系统相对较新，通常具有更多的物理内存。这并不意味着特定系统实际上拥有它或您的流程应该使用它。例如，许多人已经构建了具有 1GB RAM 的 64 位家庭文件服务器以降低成本。我知道很多人会因为一个随机进程强迫他们的 DBMS 交换而感到恼火，因为它只考虑自己。
| 归档时间： |
|
| 查看次数： |
3023 次 |
| 最近记录： |