> Причём спрос на ограничение потребления процессора был ещё до появления KVM.

cgroups не катят?

Обещали более четко разделять пакеты с новыми фичами и исправления багов. И именно с 14-ой. Про нубов будешь в классе орать, мальчик.

>Поддержка до Конца Света и больше (с) я

Или поддержка до вендекапца (с)
Как лучше?

Элементарно: смотря что наступит раньше. Это как в авто, - ТО-0 через год или 5 тыс.км.

ну да, только скачать без этого не дают. Говорят или 30 дней триала (как у всяких там пропринетаршиков) или плати бабло что бы получить бинарники - поведение 1 в 1 с пропринетарщиками. Для них нет смысла делать код открытых проектов стабильным - иначе у них никто сборку пакетов и фикс багов не купят, вот и суют по всюду глючный бетакод. который потом сами же и фиксят за ваши деньги.

> обновления в данном случае - это патчи для закрытия дыр в безопасности или бэкпортированные стабилизированные фишки.

офигеть - почитать комит лог и взять чужой патч уже считается гигантской работой. По сути их работа - взять у клиента описание баги, посмотреть пофиксена она в mainstream, если пофиксена - взять фикс и предложить клиенту сборку. _И_ВСЕ_. офигеть какая тяжелая работа.

>если вдруг хочешь поставить на сервер с 4мя ядрами Socket == процессор, емнип )

>>Обещали более четко разделять пакеты с новыми фичами и исправления багов. И именно с 14-ой. Про нубов будешь в классе орать, мальчик.

Иди уроки делай, школота

> cgroups не катят?

Покатит, когда будет реализовано ограничение CPU.

Пусть лучше Zimbra притормаживает

А чем на джаву nice + ionice не угодили?

>А чем на джаву nice + ionice не угодили?

Как nice выставит лимит по использованию 4 ядер до определенного уровня, скажем 25% на все ядра, остальные 75% расходовать на другие виртуалки? Мне не нужны стабильные тормоза (именно такой результат дает nice). Мне нужны тормоза только при пиковых нагрузках.

> офигеть - почитать комит лог и взять чужой патч уже считается гигантской работой. По сути их работа - взять у клиента описание баги, посмотреть пофиксена она в mainstream, если пофиксена - взять фикс и предложить клиенту сборку. _И_ВСЕ_. офигеть какая тяжелая работа.

Всё верно. Но есть одно «но»: всё описанное Вами шоколадно выглядит в начале жизни дистрибутива, а годика этак через четыре, когда уже и мажорные версии программ далеко впереди, и патч, закрывающий дыру, совсем не «ложится» на исходники из дистрибутива, вот тогда это и является «офигеть какая тяжелая работа». Причём чем дальше - тем больше поддержка пакетов дистрибутива ложится на плечи маинтейнеров дистра.

Мне не нужны стабильные тормоза (именно такой результат дает nice). Мне нужны тормоза только при пиковых нагрузках.

Nice и задаёт приоритет планировщика, когда ресурсов CPU не хватает. Если других процессов нет, любой nice сожрёт весь доступный cpu.

Да, и еще. Именно CPU quota жёстко лимитирует CPU, даже если есть свободные ресурсы («постоянные тормоза»). Поэтому он интересен в основном тем, кто продаёт CPU время за деньги.

А как системе сказать через nice, что при дефиците ресурсов процесс с PIDом таким-то получал не больше 25%? Nice задает целочисленный приоритет, а уж как им распорядится планировщик - одному Алгоритму известно.

>даже в гноме по дефолту в контекстном меню есть «распаковать сюда» и «открыть терминал здесь».

Это в старом Гноме всегда было, потом убрали в плагин

Негадяе!

>Негадяе!

На макось переглядели, там тоже для этого плагин нужен)

[sanja@diego ~]$ lsb_release -irsc && uname -r
RedHatEnterpriseServer 6.0 Santiago
2.6.32-71.el6.i686

в принципе ничего, жить можно))))

>также отменена поддержка RHEL6 в качестве хоста Xen;

Чем он-то помешал??

Отличная новость. Особенно радуют доработки под 64.

>Для них нет смысла делать код открытых проектов стабильным - иначе у них никто сборку пакетов и фикс багов не купят, вот и суют по всюду глючный бетакод. который потом сами же и фиксят за ваши деньги.

ты что-то путаешь. Red Hat не продаёт код, они продают помощь в решении конкретных проблем, которые могут возникнуть даже при использовании продуктов даже с идеальным кодом

>>Ты б еще сказал, что debian не нужен, потому что есть ubuntu.

приходится использовать убунту 10.04 LTS потому что дебианы совсем охренели с выходом 6-й версии. релиза нет и нет. и смысла то переходить с этой убунту никакого нет - то же самое ядро, но в убунту всё оттестировано в реальной жизни за полгода уже, а релиза дебиана так и нет. кретины руководят в дебиан.

ты что-то путаешь. Debian'овцы вовсе не держат Squeeze в застенках от общественности, testing сегодня также тестируется в реальной жизни. Тем более, что после заморозки Squeeze уже практически не изменится, только в сторону большей стабильности. Можешь возвращаться на теплый ламповый Debian.

А как системе сказать через nice, что при дефиците ресурсов процесс с PIDом таким-то получал не больше 25%? Nice задает целочисленный приоритет, а уж как им распорядится планировщик - одному Алгоритму известно.

Нужно просто по другому ставить задачу. Любой серьезный продукт тестируется под нагрузкой. Вот под нагрузкой и выясните, какой nice вам нужен. Так же, как выяснили «не больше 25% CPU». А если 25% взят с потолка, оттуда же можно взять и значения для nice.

Во-вторых, система не только из CPU состоит. I/O при 25% CPU может убить всю вашу систему, заняв шину данных. И так далее. Серьезной системе в любом случае нужен серьезный тюнинг.

>>С корпоративных, на которые приходится почти половина серверов

О-ло-ло! Это же что же весь парк «корпораций» это серверы для обслуживания инраструктуры AD? Интересные такие корпорации...

Ну тогда приводи статистику использования виндоус серверов

свали отсюда уже, свидомый ты наш.

А CentOS?

Когда ждать CentOS 6? Через какое время обычно выходят центосовские версии после редхата?

Вот под нагрузкой и выясните, какой nice вам нужен.

Только так, разумеется)) Проблема в том, что значение nice - это пожелание планировщику доброго утра, а не лимит использования ресурсов процессом. Можно будет до мушек в глазах перебирать значения приоритетов, но не добиться от системы предсказуемого поведения. Впрочем, это всё же редкий случай, я думаю.

Только так, разумеется)) Проблема в том, что значение nice - это пожелание планировщику доброго утра, а не лимит использования ресурсов процессом. Можно будет до мушек в глазах перебирать значения приоритетов, но не добиться от системы предсказуемого поведения. Впрочем, это всё же редкий случай, я думаю.

Хинт: а процы у вас тоже все одинаковые для «25%»? И производительность дисковой/сетевой подсистемы одинаково грузит iowait?

Пожелание 25% сферическому процу в вакууме ничуть не уступает пожеланию Nice'у того же. А вот жестко ограничивать CPU, когда свободны ресурсы - зачем?

А вот жестко ограничивать CPU, когда свободны ресурсы - зачем?

Не, проблема не так стоит. Когда дефицита ресурсов нет, ограничивать процессы не имеет смысла. А вот когда он есть, мне бы хотелось, чтобы заданный процесс получал не меньше 50%. Потому что я знаю, например, какова зависимость производительности моего сервиса (в бизнес-операциях/с) от доли тайм-слотов, выделенных его процессу. Nice такого сделать не позволит.

Да, с дисковым IO такое планирование в общем случае не прокатит. Потому что производительность этой подсистемы зависит от типа доступа (последовательный или произвольный).

А как с 5 обновиться на 6? Кто-нибудь так пробовал?

Red Hat не продаёт код, они продают помощь в решении конкретных проблем

То есть, они, получается, заранее знают, какие конкретные проблемы возникнут, и продают помощь в решении только этих проблем, а про все остальные можно забыть? :)

Я бы сказал, что они продают контракты на поддержку, которые подразумевают, что покупатель оных не останется один на один с проблемой - что его выслушают, заявку зарегистрируют, рассмотрят и может быть решат, может быть положат в долгий ящик, а может и вообще откажутся признавать проблемой после рассмотрения. При этом без особых гарантий, что проблема будет решена.

Кстати, выпустив RHEL 6 они повысили цены - теперь поддержка некоторых продвинутых возможностей входит в состав дополнительных расширений программы поддержки, плюс в рамках модной ныне виртуализации появилась градация цен на поддержку в зависимости от количества гостей в дополнение к зависимости от количества процессоров.

А как с 5 обновиться на 6? Кто-нибудь так пробовал?

Еще не пробовали. Но в теории, поставить DVD и сказать Linux Upgrade? :)

>Nice и задаёт приоритет планировщика, когда ресурсов CPU не хватает.

1. Выставлять nice на процесс в виртуалке бесмысленно. Т.к. хост будет отдавать все процессорное время на процесс qemu.
2. Выставив nice в хост на процесс виртуалки - даст тормоза всей виртуальной системе, если в этот момент проц нагружен другим процессом/виртуалкой.

И вообще, прошу примеры в студию с описанием какие тормоза я получу при таком-то nice для 2 виртуальных машин. Мне надо чтобы процессорное время делилось как 0.75/0.25. Какие надо выставить nice и где?

RedHat продает бинарники и услуги по исправлению ошибок. Поэтому они кровно не заинтересованы что бы ошибок было мало, и любой и каждый мог собрать пакеты.

Господа, а что всё же слышно о сроках выхода дебиана 6-го?

ты что-то путаешь. Debian'овцы вовсе не держат Squeeze в застенках от общественности, testing сегодня также тестируется в реальной жизни. Тем более, что после заморозки Squeeze уже практически не изменится, только в сторону большей стабильности. Можешь возвращаться на теплый ламповый Debian.

повторяю: Ubuntu 10.04 LTS уже используется полгода в реальных условиях, всё патчено-перепатчено. используется может быть на десятках или сотнях тысяч компьютеров, в том числе и серверах. потом ещё сколько будет допиливаться релиз дебиана после релиза и сколько будет апдейтов (с перезагрузками). Lenny был не особо нужен (многих устраивал Etch, так как там удачное ядро. плюс вполне неплох был Ubuntu 8.04 LTS с ядром не сильно отличающимся от Lenny-евского), а уж Сквиз точно не нужен (УЖЕ не нужен) так как есть уже давно Ubuntu LTS, SLES, теперь и RHEL, и всё на одном ядре.

>По сути их работа - взять у клиента описание баги, посмотреть пофиксена она в mainstream, если пофиксена - взять фикс и предложить клиенту сборку

rpm -qa | wc -l

1484

1. Выставлять nice на процесс в виртуалке бесмысленно. Т.к. хост будет отдавать все процессорное время на процесс qemu. 2. Выставив nice в хост на процесс виртуалки - даст тормоза всей виртуальной системе, если в этот момент проц нагружен другим процессом/виртуалкой.

«The current version of the Red Hat Enterprise Linux kernel supports setting relative priorities for any process including virtual machines. This priority is for an aggregate measure of CPU, memory, network and disk IO for a given virtual machine, and provides the first level of Quality of Service (QoS) infrastructure for virtual machines.»

Есть смысл, есть. Так и устанавливают приоритет VM. Стандартными средствами шедулера. Откуда там внезапно тормоза должны появиться? http://www.redhat.com/f/pdf/rhev/DOC-KVM.pdf Там же читайте про CFS и cgroups, особенно про то, что лимитируется не только CPU, но и другие ресурсы.

«The CFS scheduler has been extended to include the CGroups (control groups) resource manager that allows processes, and in the case of KVM – virtual machines, to be given shares of the system resources such as memory, cpu and I/O. Unlike other virtual machine schedulers that give proportions of resources to a virtual machine based on weights, cgroups allow minimums to be set not just maximums, allowing guaranteed resources to a virtual machine but allowing the virtual machine to use more resources if available»

Мне надо чтобы процессорное время делилось как 0.75/0.25. Какие надо выставить nice и где?

Про влияние I/O и 25% попугаев на CPU читайте тред выше.

хренасе поддержка

если бы не RH, то до сих пор бы сидели на убогих kernel 2.2+libc5+egcs 1.1.2, поэтому скажи им спасибо за то, что все их разработки есть в vanila и бесплатном centos

На сколько я знаю, KVM — не PV и будет заметно медленнее на вводе-выводе и памяти.

virtio диски и сетевые давно есть

Почитал про cgroups. Да это решение. RH-based only. Без патчей от RH, ИМХО, лучше с этим не связываться (как раз мой случай) :)

>а уж Сквиз точно не нужен (УЖЕ не нужен) так как есть уже давно Ubuntu LTS, SLES, теперь и RHEL, и всё на одном ядре.

У жигулей 4 колеса (а ездит фигово), в газелях есть люки (текут во всех новых машинах). В общем такие фичи давно есть в самых разных машинах, поэтому все они в новых машинах других производителей востребованы не будут следуя вашей логике. Пусть в убунте регулятор громкости в ритмбоксе починят (а то плеер часто вываливается, когда его крутишь, но ведь в Лёне работает и не отваливается) и разрешат на некоторые приложения неразрешимые зависимости или уберут такие пакеты вообще нафиг чтобы люди не мучились и сразу собирали из исходником (ох сколько мороки доставил asterisk на 9.10).

Так что пользуйся мопедом, а я пока подожду. Кстати в приведенных дистрибутивах («Ubuntu LTS, SLES, теперь и RHEL, и всё на одном ядре»)ядра-то не ванильные.

>virtio диски и сетевые давно есть

И как они, диски, по производительности?

Ubuntu LTS - не мопед. это реально используемый дистр, в том числе серверный. а колёсики в поделках - не интересуют. дистр в основном это платформа а не свистелки. а Ubuntu LTS платформы реально надёжные.

ядра-то не ванильные

да, слаке нужно подохнуть хотя-бы только для того, что-бы перестали думать что в дистр можно пихнуть ванильное ядро.

> да, слаке нужно подохнуть хотя-бы только для того, что-бы перестали думать что в дистр можно пихнуть ванильное ядро.

Гыгы, неосиливший сборку ядра, сразу видно. А слака - она и тебя переживёт.

мне не надо компилировать ядро. я не девелопер ядра и не мэинтейнер пакетов ядра.

Неужели не интересно понять, как работает Linux, собрать LFS своими руками, собрать ядро, сделав его конфиг с нуля? Неужели интересно быть таким узколобым?

интересно было. собирал. хватит. есть люди (профессионалы) которые делают своё дело - собирают и патчат ядро. а собирать и патчить ядро только потому что Патрик не понимает что реально нужно патчить в дистрибутивном ядре и что надо было при сборке поставить ещё «пару галочек» - мы не будем. слака это маргинальный дистрибутив для фанатов и странных людей. или для тех кому вобщем мало что от линукс надо и кому хватает 2Gb RAM.