>>В OVZ с cpu шедуллингом такого нет: cpulimit просто не даст превысить
>>cpu время процессу, даже если у него высокий cpuunits(и шедуллер часто
>>передает ему управление, что полезно для приложений, требующих высокой отзывчивости, например,
>>ip телефонии), и никого убивать не будет.
>
>Хм. То ли я туплю, то ли не понимаю, чем это лучше
>настройки базового приоритета… Давайте внесем ясность, о каких именно лимитах мы говорим?
Если cputime, то его использование чревато отказом в обслуживании (FreeBSD ядром будет прибит процесс, съевший все, что полагается пользователю)
-cur и -max никак не помогут избежать отказа в обслуживании. Что еще остается? Старичек renice.
А вот такого лимита, который бы и в top лимитировал группу процессов так, что бы они показывали всегда, например, 30%, и при этом не прибивались ядром, нет
Если cpuset, то это всего лишь навсего распределение процессов по ядрам (очень давно есть в Линухе), в том же ovz это еще один параметр, vcpus
Кроме того, в OpenVZ, внутри контейнера для вас доступны все те же renice, limit.conf (аналог в Линухе лимитов PAM login.conf), и т д
Зачем это нужно? А вот представьте, у Вас есть железка (или две, три, железки) и куча сервисов. Среди них не только web.
На процессы пользователя CGI лимиты, конечно, ставить можно, а вот на postfix в почтовом сервере, или Apache для модульного PHP, или какой еще сервис, вроде Asterisk, это чревато отказом в обслуживании(зачем вообще тогда эти лимиты нужны? Уж лучше пусть тормозит часто, и иногда виснет под нагрузкой, или по-старинке разнести на каждый самый слабый сервис по железке)
И на каждый контейнер Вы можете поставить, например:
1. На сборочный контейнер, высокий cpulimit, много vcpus (что бы make -j <много цифр>), маленький cpuunits (что бы не мешало соседям)
Внутри, что бы можно было комфортно наблюдать за сборкой, для терминала какого-нибудь пользователя максимальный приоритет средствами PAM.
2. На сервис IP-телефонии, много cpuunuits, но мало cpulimit (кстати, в OpenVZ, оно, к моему удивлению, действительно нормально работает, если разобраться с Zaptel)
3. На почтовый сервис, средненько-маленькое значение cpuunits, да и cpulimit (почта может и по-тормозить, вебморде внутри можно уже поставить процессам больший приоритет)
4. На каждый контейнер под каждый сайт, большой cpulimit (что бы скрипты могли разогнаться), и маленький cpuunits, в сравнении с IP-телефонией, и, в зависимости от важности сайта, соотвествующее количество воркеров
Внутри(!) можно так же ставить лимиты через PAM и renice
5. Для остальных сервисов (Samba всякие, Squid'ы, и т д) на основе таких же идей.
Если перемудрим, и что-то будет тормозить, можно мовнуть _online_ сервис на другую железку.
Аналог этого же в Jails? Имхо, будет очень и очень не скоро.
