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