Найбільша дозволена максимальна кількість відкритих файлів у Linux

Чи існує (технічне чи практичне) обмеження на величину максимальної кількості відкритих файлів у Linux? Чи є якісь несприятливі ефекти, якщо ви налаштуєте їх на дуже велику кількість (скажімо, 1-100 М)?

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

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

Але з огляду на те, наскільки абсурдно багато сучасних систем ОЗУ порівняно з системами 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і, отже, запобіжить більш інтенсивному (можливо, не підлягає відновленню) комп'ютерному замороженню.

Якщо у вас немає точних причин для збільшення будь-якого з цих меж, вам слід уникати цього і краще спати.

Технічно обмежено максимальним значенням безпідписаного довгого (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 man ви бачите, що 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 це число просто означає нескінченність. Ви завжди будете досягати інших обмежень ресурсів, перш ніж коли-небудь потрапити на це. Якщо ви змінили жорсткий ліміт у системі, що перевищує його, вам доведеться змінити параметри ядра.