Вопрос: Практические максимальные открытые файловые дескрипторы (ulimit -n) для системы с большими объемами


Недавно мы начали нагружать тестирование нашего приложения и заметили, что он закончил файловые дескрипторы примерно через 24 часа.

Мы используем RHEL 5 на Dell 1955:

Процессор: 2 x Dual Core 2.66GHz 4MB 5150 / 1333FSB ОЗУ: 8 ГБ оперативной памяти Жесткий диск: 2 х 160 ГБ 2,5 "жестких диска SATA

Я проверил лимит дескриптора файла и был установлен в 1024. Учитывая, что наше приложение может иметь около 1000 входящих соединений, а также 1000 исходящих соединений, это кажется довольно низким. Не говоря уже о реальных файлах, которые нужно открыть.

Моя первая мысль состояла в том, чтобы просто увеличить параметр ulimit -n на несколько порядков, а затем повторно запустить тест, но я хотел знать любые потенциальные последствия слишком высокой установки этой переменной.

Есть ли какие-либо рекомендации по настройке этого, кроме определения количества файловых дескрипторов, которые теоретически может открыть наше программное обеспечение?


69
2017-07-31 22:35


Источник




Ответы:


Эти ограничения исходили из того времени, когда несколько «нормальных» пользователей (а не приложений) могли бы делиться сервером, и нам нужны были способы защитить их от использования слишком большого количества ресурсов.

Они очень низки для высокопроизводительных серверов, и мы обычно устанавливаем их на очень высокое число. (24k или около того) Если вам нужны более высокие номера, вам также необходимо изменить параметр sysctl file-max (обычно он ограничен 40k на ubuntu и 70k на rhel).

Настройка ulimit:

# ulimit -n 99999

Файлы Sysctl max:

#sysctl -w fs.file-max=100000

Кроме того, и очень важно, вам может потребоваться проверить, есть ли у вашего приложения утечка дескриптора памяти / файла. Используйте lsof, чтобы увидеть все, что было открыто, чтобы узнать, действительны они или нет. Не пытайтесь изменить свою систему для работы с ошибками приложений.


69
2017-08-01 13:08



@sucuri Спасибо. Мы определенно обеспокоены утечками ресурсов, но это, похоже, не так. Мы наблюдали как lsof, так и netstat, и хотя цифры высоки, они не растут, они расширяются и сокращаются. Я ожидаю, что если будет утечка, количество открытых сокетов или дескрипторов со временем будет расти. - Kevin
ulimit ограничение не для пользователя, а для каждого процесса! Видеть unix.stackexchange.com/questions/55319/...  И fs.file-max настройка для сервера в целом (так что все процессы вместе). - Tonin


Вы всегда можете просто

cat /proc/sys/fs/file-nr

Во время ситуации с высокой нагрузкой, чтобы увидеть, сколько файловых дескрипторов используется.

Что касается максимума - это просто зависит от того, что вы делаете.


13
2018-05-18 12:22



Здесь я думал, что 143000 был достаточно хорош, когда приведенная выше команда показала мне 8288 0 793377! - Sridhar-Sarnobat


Если файловые дескрипторы являются сокетами tcp и т. Д., Вы рискуете использовать большой объем памяти для буферов сокетов и других объектов ядра; эта память не будет заменяемой.

Но в противном случае нет, в принципе, проблем не должно быть. Обратитесь к документации по ядру, чтобы попытаться определить, сколько памяти ядра она будет использовать, и / или протестировать ее.

Мы запускаем серверы баз данных с дескрипторами файлов размером ~ 10 тыс. Открытых (в основном, на реальных дисковых файлах) без серьезной проблемы, но они 64-битные и имеют множество бара.

Параметр ulimit является для каждого процесса, но также существует системный предел (по умолчанию 32k)


6
2017-08-01 12:27





Я лично не знаю о каких-либо лучших практиках. Это несколько субъективно в зависимости от системной функции.

Помните, что 1024, которые вы видите, это ограничение для каждого пользователя, а не общесистемный предел. Посмотрите, сколько приложений вы используете в этой системе. Это единственный? Пользователь, который запускает это приложение, делает что-то еще? (У вас есть люди, использующие эту учетную запись для входа и запуска скриптов, которые могут потенциально сбежать?)

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


2
2017-07-31 22:53



@Grahamux Система предназначена для этого приложения, и пользователь, запускающий приложение, запускает это приложение. Я часть внутренней команды разработчиков, поэтому никакой помощи нет. - Kevin
Предел не для каждого пользователя, а для каждого процесса. Видеть unix.stackexchange.com/questions/55319/... - Tonin


Это мне кажется одним из тех вопросов, на которые лучше всего ответил «проверять его в среде разработки». Я помню, как много лет назад Солнце нервничало, когда вы с ним спорили, но не настолько нервничали. Это ограничение в то время было также 1024, так что я немного удивлен, увидев, что теперь это то же самое для Linux, похоже, что он должен быть выше.

Я нашел следующую ссылку образовательной, когда я googled для ответов на ваш вопрос: http://www.netadmintools.com/art295.html

И это тоже: https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible


1
2017-08-01 00:51