Наибольшее допустимое максимальное количество открытых файлов в Linux
На самом деле, мне проще использовать файлы рабочего стола для установки JAVA_HOME для исполняемого файла. Например, для IntelliJ, поскольку мой JAVA_HOME находится в /opt/java, а моя установка идеи в /opt/idea, я бы использовал файл рабочего стола, содержащий:
[Desktop Entry]
Type=Application
Name=Idea
Comment=IntelliJ Idea
Icon=/opt/idea/bin/idea.png
Exec=env JAVA_HOME=/opt/java /opt/idea/bin/idea.sh
Terminal=false
Categories=Development;IDE;Java;
StartupWMClass=jetbrains-idea
Затем вы можете использовать этот файл рабочего стола в любой среде рабочего стола.
Edit: Забыл указать, что вы должны сохранить файл *.desktop в ~/.local/share/applications, чтобы иметь возможность найти и использовать его в среде рабочего стола Gnome.
Я подозреваю, что основная причина ограничения заключается в том, чтобы избежать чрезмерного потребления памяти (каждый дескриптор открытого файла использует память ядра). Он также служит защитой от ошибок приложений, утекающих файловые дескрипторы и потребляющих системные ресурсы.
Но учитывая, насколько абсурдно много оперативной памяти современные системы по сравнению с системами 10 лет назад, я думаю, что сегодня значения по умолчанию довольно низкие.
В 2011 году жесткое ограничение по умолчанию для файловых дескрипторов в Linux было и увеличено с 1024 до 4096 .
Некоторое программное обеспечение (например, MongoDB) использует намного больше файловых дескрипторов, чем установлено по умолчанию. Специалисты MongoDB рекомендуют увеличить этот предел до 64 000 . Я использовал rlimit_nofile из 300 000 для некоторых приложений.
Пока вы сохраняете мягкий предел по умолчанию (1024), вероятно, довольно безопасно увеличить жесткое ограничение. Программы должны вызывать setrlimit () , чтобы поднять свой предел выше мягкого, но все еще ограничены жестким пределом.
См. Также некоторые связанные вопросы:
Последствия не будут Обычно это не наблюдается, но модуль ввода-вывода ядра должен заботиться обо всех этих открытых файловых дескрипторах, и они также могут влиять на эффективность кеширования.
Такие ограничения имеют то преимущество, что защищают пользователя от их собственных (или третьих лиц) ошибок. Например, если вы запускаете небольшую программу или сценарий, который выполняет бесконечное ветвление, он в конечном итоге заблокирует один из ulimit s и, таким образом, предотвратит более интенсивное (возможно, безвозвратное) зависание компьютера.
Если у вас нет точных причин для увеличения любого из этих ограничений, вам следует избегать этого и лучше спать.
Думаю, ваше беспокойство понятно, но, скорее всего, 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 это число просто означает бесконечность. Вы всегда достигнете других пределов ресурсов, прежде чем достигнете этого. Если вы изменили жесткое ограничение в системе сверх того, что оно есть, вам придется изменить параметры ядра.
Технически ограничен максимальным значением 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 */
};