>[оверквотинг удален]
>>>Если cputime, то его использование чревато отказом в обслуживании (FreeBSD ядром будет
>>>прибит процесс, съевший все, что полагается пользователю)
>>
>>Угу. Это про застрявшие CGI. Демонам cputime никто, разумеется, не выставляет.
>>>-cur и -max никак не помогут избежать отказа в обслуживании. Что еще
>>>остается? Старичек renice.
>>
>>«Старое» не всегда означает «неэффективное». :)
>
>Значит. прочитайте внимание про cpuunits (см. ниже)
>[оверквотинг удален]
>>А надо? Вроде как логично именно распределять приоритеты: вот эта задача важнее,
>>она получит больше CPU, а когда она будет простаивать — остальные
>>будут пользоваться тем же CPU сколько угодно — имеем максимально полное
>>испольование ресурсов железки.
>
>Нужно: ставим мало cpulimit(что бы другим не мешало), но много cpuunits, для
>высокой интерактивности сервисов (нужно IP-телефонии, но не только, для БД тоже
>не помешает, хотя, конечно, делать мягкий реалтайм на контейнерах бред, но
>скорость транзакций часто критичный фактор).
>Перечитайте, пожалуйста, еще раз примеры.
Давайте начнём с того, что cpuunits — это абстракция, и ещё чем их больше, тем тормознутее будет система, из-за виртуальных переключений контекста — физическое количество процессоров ведь то же самое. Вы гонитесь за фичами, но давайте всё же вспомним исходную задачу: 1. Давать определённым процессам более высокий (СУБД, realtime-приложения) или более низкий (компилятор) приоритет; 2. По возможности гарантировать наличие свободных процессоров для неотложного выполнения (realtime-приложения). Обе эти задачи во FreeBSD выполняются — по-другому, чем в Linux+OpenVZ, но выполняются, более того, средства управления в контейнерах те же, что для обычной системы, безо всяких vzctl.
Я не буду спорить, что OpenVZ в чём-то «круче». Только кому и зачем вы это доказываете?
