Чому кількість відкритих файлів обмежена в Linux?

136

Зараз я знаю, як:

знайти ліміт відкритих файлів за процес: ulimit -n
підраховувати всі відкриті файли за всіма процесами: lsof | wc -l
отримати максимально дозволену кількість відкритих файлів: cat /proc/sys/fs/file-max

Моє запитання: Чому в Linux існує обмежена кількість відкритих файлів?

open-files limit

— xanpeng
джерело

2

@Rob Googled трохи і вияви, що це вилка бомба , чи можна це використовувати для пояснення ліміту відкритого файлу?

— xanpeng

6

Ну а обмеження кількості процесів і обмеження файлів важливі, тому такі речі, як вилочні бомби, не зламають сервер / комп’ютер для всіх користувачів, лише користувач, який це робить, і лише тимчасово. В іншому випадку хтось із спільного сервера міг би відключити forkbomb і повністю збити його для всіх користувачів, а не лише їх самих.

— Роб

3

Приємно підсумовуючи кілька дуже корисних команд! : +1:

— Джошуа Пінтер

7

@Rob, бомба fork не має нічого спільного з нею, оскільки обмеження файлу відбувається за кожний процес, і кожен раз, коли ви розкручуєте, він не відкриває нову ручку файлу.

— psusi

86

Причина полягає в тому, що операційній системі потрібна пам'ять для управління кожним відкритим файлом, а пам’ять - обмежений ресурс - особливо для вбудованих систем.

Як користувач root ви можете змінити максимум кількості відкритих файлів за процес (через ulimit -n) та за систему (наприклад echo 800000 > /proc/sys/fs/file-max).

— йофель
джерело

21

Існує також причина безпеки: якби не було обмежень, програмне забезпечення userland могло б створювати файли нескінченно, поки сервер не вийде з ладу.

— Корен

15

@Coren Тут обговорювані обмеження призначені лише для кількості відкритих обробників файлів. Оскільки програма також може закрити обробники файлів, вона може створити стільки файлів і великі розміри, скільки хоче, доки не заповниться весь наявний диск на диску. Щоб цього не допустити, можна використовувати дискові квоти або окремі розділи. Ви вірні в тому сенсі, що один аспект безпеки - це запобігання виснаженню ресурсів - і для цього існують обмеження.

— jofel

1

@jofel Дякую Я думаю, що ручки відкритого файлу представлені екземплярами stru-файлу , а розмір цієї структури досить невеликий (рівень байтів), тож чи можу я встановити /.../file-maxдосить велике значення, доки пам'ять не буде використана?

— xanpeng

7

@xanpeng Я не фахівець з ядра, але, наскільки я можу бачити, типово для file-maxрозміру оперативної пам’яті поділяється на 10k. Оскільки реальна пам'ять, що використовується на обробник файлів, повинна бути значно меншою (розмір struct fileплюс деяка залежна від драйвера пам'ять), це здається досить консервативним обмеженням.

— jofel

63

Зверніть увагу, що lsof | wc -lпідсумовується багато дублюваних записів (роздвоєні процеси можуть обмінюватися файлами файлів тощо). Це число може бути набагато вищим, ніж встановлений ліміт /proc/sys/fs/file-max.

Щоб отримати поточну кількість відкритих файлів з точки зору ядра Linux, зробіть це:

cat /proc/sys/fs/file-nr

Приклад: Цей сервер має 40096 з максимально відкритих 65536 файлів, хоча lsof повідомляє про значно більшу кількість:

# cat /proc/sys/fs/file-max
65536
# cat /proc/sys/fs/file-nr 
40096   0       65536
# lsof | wc -l
521504

— grebneke
джерело

1

Як lsofбуде повідомлено про багато файлів двічі або більше, наприклад /dev/null, ви можете спробувати найкращу здогадку з:lsof|awk '{print $9}'|sort|uniq|wc -l

— Іван

ви можете використовувати, lsof|awk '!a[$NF]++{c++}END{print c}'щоб отримати не повторюваний кількість відкритих файлів.

— Р ....

18

Я думаю, що це багато в чому з історичних причин.

Дескриптор Unix файл являє собою невелике intзначення, що повертається функціями , як openі creat, і передається read, write, closeі так далі.

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

Більш сучасні системи мають більш високі межі, але зберегли ту саму загальну схему, значною мірою за інерцією.

— Кіт Томпсон
джерело

1

20 був обмеженням Solaris для структур даних FILE мови мови C. Кількість файлових ручок завжди була більшою.

— Лотар

@Lothar: Цікаво. Цікаво, чому межі відрізнялися б. З огляду на filenoта fdopenфункції, я б очікував, що вони будуть майже взаємозамінними.

— Кіт Томпсон

Файл unix - це більше, ніж просто повернута ручка файлу (int). Є дискові буфери та блок управління файлами, який визначає поточне зміщення файлу, власника файлу, дозволів, inode тощо

— ChuckCottrill

@ChuckCottrill: Так, звичайно. Але більша частина цієї інформації повинна зберігатися, доступ до файлу через intдескриптор чи a FILE*. Якщо у вас відкрито більше 20 файлів через open(), не fdopen()вдалося б ?

— Кіт Томпсон