Чем отличаются 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
Warner

Ответы:


28

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

Риск повышения производительности не увеличивается file-max. В современных дистрибутивах максимальный набор FD довольно высок, тогда как в прошлом требовалось перекомпиляция и модификация ядра для увеличения после 1024. Я не увеличил бы всю систему, если у вас нет технической необходимости.

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


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

Да, настройки могут быть установлены как глобально, так и для каждого пользователя.
Уорнер

Если я правильно понял ваш пост, это неправда. Это процесс, созданный пользователем xy, и он ограничен максимальным значением файловой системы, определенным в /etc/sysctl.conf
Jeredepp

3
ulimitПредел не для каждого пользователя, но в процессе! См. Unix.stackexchange.com/questions/55319/…
Тонин

@ Тонин - Да, этот ответ просто неправильный.
Немо

11

Ограничение ulimit для каждого уникального пользователя. Таким образом, user1, независимо от того, сколько раз вошли в систему или запущены процессы, будет ограничен 1024. Это объединено.

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

Я имею в виду, что если какой-то пользователь запустил 4 процесса, а конфигурация ulimit для 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 было 3 открытых файловых дескриптора (stdout, stdin и stderr)

Извините, если я совершенно не прав или неправильно понял ответ.


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