Як відрізняються ulimit -n та / proc / sys / fs / file-max?


32

Я зауважую, що на новому зображенні CentOS, яке я щойно завантажив з EC2, що за промовчанням ulimit є 1024 відкритих файлів, але / proc / sys / fs / file-max встановлено на 761,408, і мені цікаво, як працюють ці два межі разом. Я здогадуюсь, що ulimit -n - обмеження кількості дескрипторів файлів на користувача, тоді як / proc / sys / fs / file-max є загальносистемним? Якщо це так, скажіть, що я ввійшов два рази як один і той самий користувач - чи має кожен користувач, що ввійшов, має обмеження 1024 у кількості відкритих файлів, чи це обмеження 1024 об'єднаних відкритих файлів між кожним із цих зареєстрованих- у користувачів?

І чи сильно впливає на ефективність встановлення максимальних дескрипторів файлів на дуже велику кількість, якщо ваша система ніколи не відкриває дуже багато файлів?


Додані теги: bash linux kernel system-resources
Warner

Відповіді:


28

file-max- це максимальний дескриптор файлів (FD), виконаний на рівні ядра, який неможливо перевершити всі процеси без збільшення. Застосовується ulimitна рівні процесу, який може бути меншим ніж file-max.

Не збільшуючи ризик впливу на продуктивність за рахунок збільшення file-max. Сучасні дистрибутиви мають максимальний набір FD досить високим, тоді як в минулому він потребував перекомпіляції та модифікації ядра, щоб збільшити минулі 1024. Я б не збільшував загальносистемні, якщо у вас немає технічної потреби.

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


Чи правильно я розумію, що обмеження для користувачів, встановлені за допомогою ulimit, однакові для всіх користувачів? Чи є спосіб використовувати різні значення на користувача чи ні?
Олівер

Так, налаштування можна встановлювати як глобально, так і на основі кожного користувача.
Warner

Якщо я отримаю вашу посаду правильно, це неправда. Цей процес породжений користувачем xy, і це обмежено максимальною файловою системою, визначеною в
/etc/sysctl.conf

3
ulimitМежі не для кожного користувача, але в процесі! Дивіться unix.stackexchange.com/questions/55319/…
Тонін

@Tonin - Так, ця відповідь просто неправильна.
Немо

11

Обмеження ulimit визначено для кожного унікального користувача. Таким чином, користувач1, незалежно від того, скільки разів увійшов у систему або працював, буде обмежений 1024. Це поєднується.

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

Що я маю на увазі, якщо якийсь користувач запустив 4 процеси, а обмежена конфігурація для FD - 1024, кожен процес може відкрити 1024 FD. Користувач не обмежується 1024 FD, але процесами, які запускаються цим користувачем.

Наприклад:

me@superme:~$ ulimit -n
1024
me@superme:~$ lsof | grep $USER | wc -l
8145

Ось приклад perl, де ми досягаємо ліміту (це обмеження за процес):

#!/usr/bin/perl

$count = 0;
@filedescriptors;

while ($count <= 1024) {
    $FILE = ${count};
    open $FILE, ">", "/tmp/example$count" or die "\n\n FDs: $count $!";
    push(@filedescriptors, $FILE);
    $count ++;
}

Результат:

FDs: 1021 Too many open files at ./test.pl line 8.

1021 тому, що до досягнення циклу while (stdout, stdin та stderr) були три дескриптори відкритих файлів

Вибачте, якщо я абсолютно помиляюся або я неправильно зрозумів відповідь.


Отже, ви праві. @ Відповідь Уорнера в цьому сенсі неправильна, оскільки ліміт базується на основі процесу, а не на кожного користувача
filipenf
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.