Есть ли (технический или практический) предел того, насколько велико можно настроить максимальное количество открытых файлов в Linux? Есть ли какие-либо побочные эффекты, если вы настроите его на очень большое число (скажем, 1-100M)?
Я имею в виду использование сервера здесь, а не встроенные системы. Программы, использующие огромное количество открытых файлов, могут, конечно, потреблять память и работать медленно, но меня интересуют побочные эффекты, если ограничение настроено намного больше, чем необходимо (например, память, используемая только конфигурацией).
linux
files
limit
open-files
Sampo
источник
источник
Ответы:
Я подозреваю, что основная причина ограничения заключается в том, чтобы избежать чрезмерного потребления памяти (каждый дескриптор открытого файла использует память ядра). Он также служит защитой от ошибочных приложений, утечки файловых дескрипторов и использования системных ресурсов.
Но, учитывая, насколько абсурдно много оперативной памяти в современных системах по сравнению с системами 10 лет назад, я думаю, что значения по умолчанию сегодня довольно низкие.
В 2011 году жесткое ограничение по умолчанию для файловых дескрипторов в Linux было увеличено с 1024 до 4096 .
Некоторое программное обеспечение (например, MongoDB) использует намного больше файловых дескрипторов, чем ограничение по умолчанию. Люди MongoDB рекомендуют поднять этот лимит до 64 000 . Я использовал
rlimit_nofile
300 000 для определенных приложений.Пока вы сохраняете мягкий предел по умолчанию (1024), вероятно, довольно безопасно увеличивать жесткий предел. Программы должны вызывать
setrlimit()
, чтобы поднять свой лимит выше мягкого лимита, и все еще ограничены жестким лимитом.Смотрите также некоторые связанные вопросы:
источник
Воздействие обычно не было бы заметным, но модуль ввода-вывода ядра должен будет позаботиться обо всех этих дескрипторах открытых файлов, и они также могут оказать влияние на эффективность кэша.
Такие ограничения имеют то преимущество, что защищают пользователя от собственных (или третьих лиц) ошибок. Например, если вы запустите небольшую программу или сценарий, который разветвляется на неопределенный срок, он в конечном итоге заблокирует один из
ulimit
файлов и, следовательно, предотвратит более интенсивное (возможно, необратимое) зависание компьютера.Если у вас нет точных причин для увеличения какого-либо из этих ограничений, вам следует избегать этого и лучше спать.
источник
Технически оно ограничено максимальным значением unsigned long (C Lang), т. Е. 4 294 967 295
Ссылка:
fs.h
файлисточник
Я думаю, что ваша проблема понятна, но, скорее всего, Linux не будет использовать много памяти для сконфигурированных (но не используемых файловых дескрипторов) :)
Я не могу вспомнить такую проблему в моей профессиональной карьере за последние 10 лет.
С уважением.
источник
Спокойно поздно, но это должно помочь всем остальным получить ответ на этот вопрос. Практическое ограничение на количество открытых файлов в linux также может быть подсчитано с использованием максимального количества дескрипторов файлов, которые может открыть процесс.
Я видел изменения границ от системы к системе. На странице руководства getlimit вы можете увидеть, что
RLIMIT_NOFILE-1
определяет внутренние ограничения.Чтобы проверить значение RLIMIT_NOFILE, вы можете использовать приведенный ниже оператор, чтобы получить кортеж
python -c "import resource; print(resource.getrlimit(resource.RLIMIT_NOFILE))"
Кортеж возвращает результаты как (Soflimit, hardlimit). Для меня работает на нескольких системах результаты, как показано ниже
Примечание: 9223372036854775807 это число просто означает бесконечность. Вы всегда достигнете других лимитов ресурсов, прежде чем ударитесь об этом. Если вам нужно изменить hardlimit в системе сверх того, что есть, вам придется изменить параметры ядра.
источник