У моей команды недавно возникла проблема с слишком низким значением ulimit на наших серверах Apache. Мы говорили об увеличении лимита до некоторого произвольного числа, но не могли придумать никакой причины, чтобы не просто глобально не установить его на неограниченный.
Есть ли веские причины не делать этого?
Мы понимаем, что там может использоваться больше ресурсов, но, вероятно, легче справиться с использованием ресурсов, чем сбоем приложения или проблемой "вне fd".
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 () значительно увеличивается, если таблица дескрипторов файлов слишком велика (что не происходит в обычных условиях, но может произойти легко, если один из ваших процессов протекающие ручки). Это снизит общую производительность асинхронного ввода-вывода в масштабах всей системы.