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

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

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

Процессор: 2 двухъядерных 2,66 ГГц 4 МБ 5150 / 1333FSB ОЗУ: 8 ГБ ОЗУ HDD: 2 x 160 ГБ 2,5-дюймовые жесткие диски SATA

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

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

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

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

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

Настройка ulimit:

# ulimit -n 99999

Sysctl max файлы:

#sysctl -w fs.file-max=100000

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

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

cat /proc/sys/fs/file-nr

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

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

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

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

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

Настройка ulimit указана для каждого процесса, но есть и общесистемный лимит (я думаю, 32K по умолчанию)

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

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

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

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

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

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