RLIMIT_AS 在将其软限制设置为某个值时不起作用
对于进程，我为资源 RLIMIT_AS 设置了软限制值 335544320 和硬限制值 1610612736。即使设置此值后，进程的地址空间也会达到最大178MB。但我可以看到 /proc/process_number/limits 中的软限制和硬限制的值正确设置为上述值。
我想知道 RLIMIT_AS 是否在我的操作系统中工作，并且还想知道如何测试 RLIMIT_AS 功能。
我正在使用的操作系统是CentOS 5.5（64位）。
请一些人在这方面帮助我。谢谢你！
For a process, I have set a soft limit value of 335544320 and hard limit value of 1610612736 for the resource RLIMIT_AS. Even after setting this value, the address space of the process goes up to maximum 178MB. But I am able to see the value of the soft and Hard limits in /proc/process_number/limits correctly set to the above said values.
I wanted to know whether RLIMIT_AS is working in my OS and would also like to know how I can test for the RLIMIT_AS feature.
CentOS 5.5(64 bit) is the operating system that I am using.
Some please help me with regard to this. Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
所有
setrlimit()限制均为上限 /em>。只要不超出软限制，进程就可以使用所需数量的资源。从setrlimit()手册页：实际上，这意味着硬限制是软限制及其本身的上限。内核仅在进程操作期间强制执行软限制 - 仅当进程尝试更改资源限制时才检查硬限制。
在您的例子中，您为地址空间指定了 320MB 的上限，而您的进程使用了其中大约 180MB - 完全在其资源限制之内。如果您希望流程不断发展，您需要在其代码中实现这一点。
顺便说一句，资源限制的目的是保护系统，而不是调整单个进程的行为。如果一个进程遇到这些限制之一，无论您的故障处理有多好，它是否能够恢复通常都是值得怀疑的。
如果您想通过分配更多缓冲区来提高性能等方式来调整进程的内存使用情况，您应该执行以下一项或两项操作：
询问用户适当的值。在我看来，这是应该永远可能发生的一件事。用户（或系统管理员）应该始终能够控制这些事情，从而覆盖应用程序中的任何和所有猜测。
检查有多少内存可用，并尝试猜测一个合适的分配量。
作为旁注，您可以（并且应该）在编译时处理 32 位与 64 位。此类的运行时检查很容易失败并浪费 CPU 周期。但请记住，CPU“位数”与可用内存没有任何直接关系：
32 位系统确实对内存施加了限制（通常在 1-3 GB 范围内），过程可以使用。这并不意味着这么多内存实际上可用。
64 位系统相对较新，通常拥有更多的物理内存。这并不意味着特定系统实际上拥有它或者您的进程应该使用它。例如，许多人构建了具有 1GB RAM 的 64 位家庭文件服务器以降低成本。我知道很多人会很恼火，如果随机过程迫使他们的 DBMS 仅仅因为它只考虑自身而进行交换。
All
setrlimit()limits are upper limits. A process is allowed to use as much resources as it needs to, as long as it stays under the soft limits. From thesetrlimit()manual page:Practically this means that the hard limit is an upper limit for both the soft limit and itself. The kernel only enforces the soft limits during the operation of a process - the hard limits are checked only when a process tries to change the resource limits.
In your case, you specifiy an upper limit of 320MB for the address space and your process uses about 180MB of those - well within its resource limits. If you want your process to grow, you need to do it in its code.
BTW, resource limits are intended to protect the system - not to tune the behaviour of individual processes. If a process runs into one of those limits, it's often doubtful that it will be able to recover, no matter how good your fault handling is.
If you want to tune the memory usage of your process by e.g. allocating more buffers for increased performance you should do one or both of the following:
ask the user for an appropriate value. This is in my opinion the one thing that should always be possible. The user (or a system administrator) should always be able to control such things, overriding any and all guesswork from your application.
check how much memory is available and try to guess a good amount to allocate.
As a sidenote, you can (and should) deal with 32-bit vs 64-bit at compile-time. Runtime checks for something like this are prone to failure and waste CPU cycles. Keep in mind, however, that the CPU "bitness" does not have any direct relation with the available memory:
32-bit systems do indeed impose a limit (usually in the 1-3 GB range) on the memory that a process can use. That does not mean that this much memory is actually available.
64-bit systems, being relatively newer, usually have more physical memory. That does not mean that a specific system actually has it or that your process should use it. For example, many people have built 64-bit home file servers with 1GB of RAM to keep the cost down. And I know quite a few people that would be annoyed if a random process forced their DBMS to swap just because it only thinks of itself.