Перечитывала Ваше сообщение, обратила внимание, что в ответе не ответила на один тезис (хотя выше есть ответ),

>>Если cputime, то его использование чревато отказом в обслуживании (FreeBSD ядром будет
>>прибит процесс, съевший все, что полагается пользователю)
>
>Угу. Это про застрявшие CGI. Демонам cputime никто, разумеется, не выставляет.
>>-cur и -max никак не помогут избежать отказа в обслуживании. Что еще
>>остается? Старичек renice.
>
>«Старое» не всегда означает «неэффективное». :)

Значит. прочитайте внимание про cpuunits

>>А вот такого лимита, который бы и в top лимитировал группу процессов
>>так, что бы они показывали всегда, например, 30%, и при этом
>>не прибивались ядром, нет
>
>А надо? Вроде как логично именно распределять приоритеты: вот эта задача важнее,
>она получит больше CPU, а когда она будет простаивать — остальные
>будут пользоваться тем же CPU сколько угодно — имеем максимально полное
>испольование ресурсов железки.

Нужно: ставим мало cpulimit(что бы другим не мешало), но много cpuunits, для высокой интерактивности сервисов (нужно IP-телефонии, но не только, для БД тоже не помешает, хотя, конечно, делать мягкий реалтайм на контейнерах бред, но скорость транзакций часто критичный фактор).
Перечитайте, пожалуйста, еще раз примеры.