将 ulimit 全局设置为无限制有哪些潜在问题？

Question

我的团队最近在我们的 Apache 服务器上遇到了 ulimit 设置过低的问题。我们谈到将限制增加到某个任意数字，但我们想不出任何理由不只是将其全局设置为无限制。

有什么好的理由不这样做吗？

我们意识到可以使用更多资源，但处理资源使用可能比处理应用程序崩溃或“fd 不足”问题更容易。

Answer 1

ulimit 是一个在 Linux 系统上设置各种限制的接口，而不仅仅是打开文件描述符限制：

~# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

您实际上对资源设置限制的原因是因为资源是有限的。设置限制基本上可以保护您的系统免于以限制特定用户为代价而变得无响应。即使您只需要关心一个应用程序，您仍然需要确保它不会使系统停止，因此您甚至无法通过 SSH 登录来解决更多问题。

在打开文件描述符的特定情况下，如果文件描述符表太大，则使用 select() 或 poll() 调用的异步操作的开销会显着增加（这在通常情况下不会发生，但如果您的进程之一可能很容易发生正在泄漏句柄）。这将损害异步 I/O 系统范围的整体性能。