我的团队最近遇到了ulimit在我们的Apache服务器上设置太低的问题。 我们谈到增加一些任意数量的限制，但是我们不能想到任何理由不把它全面地设置为无限制。
有没有好的理由不这样做？
我们意识到可以使用更多的资源，但是处理资源使用可能比应用程序崩溃或“出错”问题更容易。
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
你实际上会设置资源限制的原因是因为资源是有限的。 设置限制基本上可以防止系统以限制特定用户为代价变得无法响应。 即使您只有一个应用程序需要关心，您仍然需要确保它不会使系统停止，所以您甚至无法通过SSHlogin来解决问题。
在打开文件描述符的特定情况下， 如果文件描述符表太大 （在通常情况下不会发生，但是如果您的某个进程可能会轻易发生），则使用select（）或poll（）调用的asynchronous操作的开销将显着增加正在泄漏手柄 ）。 这会损害系统asynchronousI / O的整体性能。