>[оверквотинг удален]
>>
>>Итого, 3:1, или, если считать по-другому, 2:0
>
>Вы судите с какой-то маркетинговой позиции: чем больше названий, тем круче. То,
>что в OpenVZ одни средства регулирования, а в jail другие, с
>меньшим количеством кнопочек, ещё не означает, что jail хуже управляется. :)
>Изобилие кнопочек — признак не столько мощности инструмента, сколько его недоделанности.
>Вы ведь не ради количества кнопочек его используете, а ради выполнения
>своей работы. Впрочем, про инструменты и задачи я ответил чуть раньше,
>повторяться не буду. Жесткий лимит на CPU, который не прибивает процессы, просто очень удобен от для разных применений от хостинга(зачем Вам давать есть чужому VPS больше, например, проданных Вами 500Mhz?) до планирования работы сервисов.
Если какой-то сервис будет есть, пусть и с меньшим приоритетом, процессорное время других сервисов, последним его достанется меньше.
Некоторым сервисам (таким, как MTA, если они, конечно, не обрабатывают 10 тысяч сообщений в минуту и даже за более короткий период времени) можно слегка тормозить в пиковые часы нагрузки на железку, это на качестве их функционирования не скажется.
Именно поэтому жесткий лимит сверху и нужен и удобен. Плюс, как я уже говорила, в коомбинации с cpuunits позволяет давать сервису интерактивность так, что он не будет прогружать cpu больше положенного.
Пожалуйста, прочитайте еще раз сценарии, которые я описала.
Что касается количества "рулилок" большое количество параметров в UBC позволяет более гибко управлять контенерами. Те, кто не хотят париться и читать документацию, могут купить PVC с проприетарным SLM(или коомбинировать с UBC для лучшей изоляции), что бы он думал за них, а ядерная память выделялась одним куском с user-mode
