Недавно мы начали нагрузочное тестирование нашего приложения и заметили, что в нем закончились файловые дескрипторы примерно через 24 часа.
Мы запускаем RHEL 5 на Dell 1955:
ЦП: 2 двухъядерных процессора, 2,66 ГГц, 4 МБ, 5150/1333 FSB ОЗУ: 8 ГБ ОЗУ Жесткий диск: 2 жестких диска SATA по 160 ГБ 2,5 дюйма
Я проверил ограничение файлового дескриптора, и оно было установлено на 1024. Учитывая, что наше приложение потенциально может иметь около 1000 входящих соединений, а также 1000 исходящих соединений, это кажется довольно низким. Не говоря уже о файлах, которые нужно открыть.
Моя первая мысль заключалась в том, чтобы просто увеличить параметр ulimit -n на несколько порядков, а затем повторно запустить тест, но я хотел знать любые потенциальные последствия установки этой переменной слишком высокого уровня.
Есть ли какие-либо рекомендации по настройке этого параметра, кроме определения количества файловых дескрипторов, которые наше программное обеспечение может теоретически открыть?
Эти ограничения возникли в то время, когда несколько «обычных» пользователей (не приложений) совместно использовали сервер, и нам нужны были способы защитить их от использования слишком большого количества ресурсов.
Они очень низкие для высокопроизводительных серверов, и мы обычно устанавливаем их на очень высокое значение. (24 КБ или около того) Если вам нужны более высокие числа, вам также необходимо изменить параметр sysctl file-max (обычно ограничивается 40 КБ на ubuntu и 70 КБ на rhel).
Настройка ulimit:
# ulimit -n 99999
Файлы Sysctl max:
#sysctl -w fs.file-max=100000
Кроме того, что очень важно, вам может потребоваться проверить, есть ли в вашем приложении утечка дескриптора памяти / файла. Используйте lsof, чтобы увидеть все, что у него открыто, чтобы узнать, действительны они или нет. Не пытайтесь изменить свою систему, чтобы обойти ошибки приложений.
Вы всегда могли просто
cat /proc/sys/fs/file-nr
В ситуации «высокой нагрузки», чтобы узнать, сколько файловых дескрипторов используется.
Что касается максимума - это просто зависит от того, что вы делаете.
Если файловыми дескрипторами являются сокеты tcp и т. Д., Вы рискуете использовать большой объем памяти для буферов сокетов и других объектов ядра; эта память не подлежит замене.
А в остальном нет, в принципе проблем быть не должно. Обратитесь к документации ядра, чтобы попытаться выяснить, сколько памяти ядра оно будет использовать, и / или протестируйте его.
Мы запускаем серверы баз данных с открытыми дескрипторами файлов ~ 10k (в основном на реальных дисковых файлах) без серьезных проблем, но они 64-битные и имеют много оперативной памяти.
Настройка ulimit для каждого процесса, но есть и общесистемный предел (32k, я думаю, по умолчанию)
Мне лично не известны какие-либо передовые методы. Это несколько субъективно в зависимости от функции системы.
Помните, что 1024 - это ограничение для каждого пользователя, а не для всей системы. Подумайте, сколько приложений вы запускаете в этой системе. Это единственный? Делает ли пользователь, запускающий это приложение, что-нибудь еще? (IE, у вас есть люди, использующие эту учетную запись для входа в систему и запуска сценариев, которые потенциально могут убежать?)
Учитывая, что коробка запускает только это одно приложение, а учетная запись, в которой запущено это приложение, предназначена только для этой цели, я не вижу вреда в увеличении вашего лимита, как вы предлагаете. Если это штатная команда разработчиков, я бы спросил их мнение. Если это от стороннего поставщика, у него могут быть особые требования или рекомендации.
Мне кажется, что это один из тех вопросов, на который лучше всего ответить «протестируйте в среде разработки». Я помню, как много лет назад Сун нервничала, когда вы с этим напутались, но не настолько. Его предел в то время также был 1024, поэтому я немного удивлен, увидев, что сейчас то же самое для Linux, кажется, он должен быть выше.
Я нашел следующую ссылку образовательной, когда искал в Google ответы на ваш вопрос: http://www.netadmintools.com/art295.html
И еще этот: https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible