☰

`ulimit -s 1048576` 的实际限制？

tag-icon • tag-icon linux memory stack
`ulimit -s 1048576` 的实际限制？

Linux 允许ulimit -s unlimited，它允许程序耗尽系统内存并使计算机崩溃。所以，一般情况下都不好。

但是，显着提高当前 8192 默认值的限制有哪些缺点limit -s 1048576？在受信任的计算机上，除了有许多失控的程序/线程组合在一起耗尽内存之外，还会发生什么不好或不受欢迎的情况？

答案1

ulimit 有硬限制和软限制。堆栈空间的硬限制通常较高。例如，在我的系统上，使用发行版默认值：

$ ulimit -S -s
8192
$ ulimit -H -s
unlimited

实际上没有任何理由更改默认的软限制。这可能会导致内存浪费。如果堆栈空间与特定进程有关，则应通过包装 shell 脚本启动该进程，该脚本仅提高该进程的软限制。作为系统配置的一部分，可以全局或按用户/组成员身份提高硬限制。

如果您确实有真正的资源限制，那么 ulimit 提供的每个进程限制确实不是一个好的机制。我会考虑另一种技术，例如 Solaris 区域、控制组（容器）或虚拟机。

是否有更高的软限制的理由？当然，由于保留的软件无法处理大量打开的文件，诸如文件描述符数量之类的事情一直保持在较低水平，而且对于人们来说，必须不断修改软限制可能会很烦人。

最后值得一提的是，当您在没有软和硬设置的情况下使用 ulimit 时，您实际上是同时更改了这两个设置。更改设置时最好使用 -S，这样就不会意外降低硬限制。

这是一个演示。

$ ulimit -n
1024
$ ulimit -H -n
524288
$ ulimit -S -n
1024
$ ulimit -n 2048
$ ulimit -H -n
2048
$ ulimit -S -n
2048

相关内容