В настоящее время у нас возникают проблемы с сервером на основе JBoss на платформе Linux - по сути, у нас заканчиваются доступные дескрипторы файлов в процессе, и сервер хрипит.
Мы установили ulimit, чтобы разрешить 10000 открытых дескрипторов файлов, и сервер постоянно дает сбой, когда открыто гораздо меньше дескрипторов.
Я заметил одну вещь: наши сценарии запуска используют chpst, и я заметил, что chpst позволяет вам устанавливать ограничения файла / процесса / памяти в качестве аргументов. Кто-нибудь знает, соблюдает ли chpst существующий системный ulimit, если не установлены явные команды, или он использует свои собственные внутренние значения по умолчанию? Если да, то где мне их найти?
Спасибо
chpst даже не учитывает то, что вы передаете в качестве аргументов. Исходный код действительно трудно читать, но strace подтверждает:
execve("/usr/sbin/chpst", ["chpst", "-o", "10000", "/bin/sh", "-c", "sleep 5"], [/* 26 vars */]) = 0
...
getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
setrlimit(RLIMIT_NOFILE, {rlim_cur=4*1024, rlim_max=4*1024}) = 0
execve("/bin/sh", ["/bin/sh", "-c", "sleep 5"], [/* 26 vars */]) = 0
...
Я бы избегал.
Не могу добавить комментарий к Оливье Тарану, и даже если это старый вопрос, я думаю, неплохо исправить неправильные утверждения (особенно если утверждение относительно недавнее).
В его strace getrlimit сообщает, что максимальное жесткое ограничение составляет 4096, и просит chpst установить мягкое ограничение на 10000. chpst делает это, но как описано в управление limits.confмягкие ограничения не могут превышать жесткие ограничения, которые устанавливаются ядром и пользователем root. Единственное, что можно сказать об этом, это то, что, возможно, chpst должен вывести предупреждение, вот и все. Конечно, не «я бы избегал».
Обратите внимание, что это означает, что исходная проблема может быть связана не с chpst, а с конфигурацией системы. chpst - это всего лишь инструмент для установки произвольных ограничений для одного процесса, это не инструмент для настройки ядер.