RLIMIT_AS无法将其软限制设置为某个值

所有

setrlimit()

限制都是上限。允许进程使用尽可能多的资源，只要它保持在软限制之下。从

setrlimit()

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