Практические максимальные дескрипторы открытых файлов (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 на несколько порядков, а затем перезапустить тест, но я хотел знать возможные последствия слишком высокой установки этой переменной.
Существуют ли передовые практики для установки этого параметра, кроме определения количества файловых дескрипторов, которые теоретически может открыть наше программное обеспечение?
5 ответов
Эти ограничения возникли в то время, когда несколько "обычных" пользователей (не приложений) разделяли сервер, и нам требовались способы защитить их от использования слишком большого количества ресурсов.
Они очень низкие для высокопроизводительных серверов, и мы обычно устанавливаем их на очень большое число. (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, поэтому я немного удивлен, увидев, что сейчас то же самое для Linux, похоже, должно быть выше.
Я нашел следующую ссылку образовательной, когда нашел свои ответы на ваш вопрос: http://www.netadmintools.com/art295.html
И этот также: https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible
Я лично не осведомлен о каких-либо лучших практиках. Это несколько субъективно в зависимости от функции системы.
Помните, что 1024 вы видите для каждого пользователя, а не для всей системы. Посмотрите, сколько приложений вы запускаете в этой системе. Это единственный? Пользователь, который запускает это приложение, делает что-нибудь еще? (IE у вас есть люди, использующие эту учетную запись для входа в систему и запуска сценариев, которые могут потенциально убежать?)
Поскольку на этом устройстве запущено только одно это приложение, а учетная запись, в которой запущено указанное приложение, предназначена только для этой цели, я не вижу вреда в увеличении вашего лимита, как вы предлагаете. Если это собственная команда разработчиков, я бы спросил их мнение. Если это от стороннего поставщика, у них могут быть определенные требования или рекомендации.