Максимально допустимое максимальное количество открытых файлов в Linux

Есть ли (технический или практический) предел того, насколько велико можно настроить максимальное количество открытых файлов в Linux? Есть ли какие-либо побочные эффекты, если вы настроите его на очень большое число (скажем, 1-100M)?

Я имею в виду использование сервера здесь, а не встроенные системы. Программы, использующие огромное количество открытых файлов, могут, конечно, потреблять память и работать медленно, но меня интересуют побочные эффекты, если ограничение настроено намного больше, чем необходимо (например, память, используемая только конфигурацией).

Я подозреваю, что основная причина ограничения заключается в том, чтобы избежать чрезмерного потребления памяти (каждый дескриптор открытого файла использует память ядра). Он также служит защитой от ошибочных приложений, утечки файловых дескрипторов и использования системных ресурсов.

Но, учитывая, насколько абсурдно много оперативной памяти в современных системах по сравнению с системами 10 лет назад, я думаю, что значения по умолчанию сегодня довольно низкие.

В 2011 году жесткое ограничение по умолчанию для файловых дескрипторов в Linux было увеличено с 1024 до 4096 .

Некоторое программное обеспечение (например, MongoDB) использует намного больше файловых дескрипторов, чем ограничение по умолчанию. Люди MongoDB рекомендуют поднять этот лимит до 64 000 . Я использовал rlimit_nofile300 000 для определенных приложений.

Пока вы сохраняете мягкий предел по умолчанию (1024), вероятно, довольно безопасно увеличивать жесткий предел. Программы должны вызывать setrlimit(), чтобы поднять свой лимит выше мягкого лимита, и все еще ограничены жестким лимитом.

Смотрите также некоторые связанные вопросы:

• /server/356962/where-are-the-default-ulimit-values-set-linux-centos
• /server/773609/how-do-ulimit-settings-impact-linux

Воздействие обычно не было бы заметным, но модуль ввода-вывода ядра должен будет позаботиться обо всех этих дескрипторах открытых файлов, и они также могут оказать влияние на эффективность кэша.

Такие ограничения имеют то преимущество, что защищают пользователя от собственных (или третьих лиц) ошибок. Например, если вы запустите небольшую программу или сценарий, который разветвляется на неопределенный срок, он в конечном итоге заблокирует один из ulimitфайлов и, следовательно, предотвратит более интенсивное (возможно, необратимое) зависание компьютера.

Если у вас нет точных причин для увеличения какого-либо из этих ограничений, вам следует избегать этого и лучше спать.

Технически оно ограничено максимальным значением unsigned long (C Lang), т. Е. 4 294 967 295

Ссылка: fs.hфайл

/* And dynamically-tunable limits and defaults: */
struct files_stat_struct {
  unsigned long nr_files;   /* read only */
  unsigned long nr_free_files;  /* read only */
  unsigned long max_files;    /* tunable THIS IS OUR VALUE */
};

Я думаю, что ваша проблема понятна, но, скорее всего, Linux не будет использовать много памяти для сконфигурированных (но не используемых файловых дескрипторов) :)

Я не могу вспомнить такую ​​проблему в моей профессиональной карьере за последние 10 лет.

С уважением.

Спокойно поздно, но это должно помочь всем остальным получить ответ на этот вопрос. Практическое ограничение на количество открытых файлов в linux также может быть подсчитано с использованием максимального количества дескрипторов файлов, которые может открыть процесс.

Я видел изменения границ от системы к системе. На странице руководства getlimit вы можете увидеть, чтоRLIMIT_NOFILE-1 определяет внутренние ограничения.

Чтобы проверить значение RLIMIT_NOFILE, вы можете использовать приведенный ниже оператор, чтобы получить кортеж

python -c "import resource; print(resource.getrlimit(resource.RLIMIT_NOFILE))"

Кортеж возвращает результаты как (Soflimit, hardlimit). Для меня работает на нескольких системах результаты, как показано ниже

(1024, 1048576) # on UBUNTU linux 
(65536, 65536)  # on amazon linux 
(1024, 9223372036854775807) # on macos 

Примечание: 9223372036854775807 это число просто означает бесконечность. Вы всегда достигнете других лимитов ресурсов, прежде чем ударитесь об этом. Если вам нужно изменить hardlimit в системе сверх того, что есть, вам придется изменить параметры ядра.