Size: a a a

OpenStack — русскоговорящее сообщество

2021 July 05

J

J in OpenStack — русскоговорящее сообщество
Я про это думал с год назад и пришел к тому что чем городить мониторинг проще с помощью весовых коэффициентов и коэффициентов оверпровиженинга ограничить максимальный steal time.
источник

VV

Vyacheslav Vershinin in OpenStack — русскоговорящее сообщество
а как ты это сможешь сделать, если сегодня у тебя 10 VM только загрузилось, а завтра они все 100% cpu хотят потребить
источник

И

Илья | 😶 ☮️... in OpenStack — русскоговорящее сообщество
самые прожорливые мигрировать на более свободный хост
источник

AY

Andrey Yakshin in OpenStack — русскоговорящее сообщество
Славик, ну ты посоветовал
источник

J

J in OpenStack — русскоговорящее сообщество
Допустим, у нас 48 ядер на хосте.
Всем ВМ выделяем не больше 60 ядер, к примеру.

И тогда уже не важно сколько там чего какая вм жрет потому что без запинивания ядер планировщик хоста будет размазывать нагрузку по всем ядрам и даже если все витуалки будут нагружать свои vCPU на 100% планировщик хоста вряд ли допустит перекос и вм от процессорного времени друг друга примерно равные куски будут отъедать.
источник

J

J in OpenStack — русскоговорящее сообщество
при таком подходе, конечно, может получиться что у тебя какие-то хосты очень слабо нагружены, если там все вм простаивают. Но зато и у клиентов есть гарантия относительно доступного процессорного времени.
источник

J

J in OpenStack — русскоговорящее сообщество
Ну а если с QoS в нове поиграть, то можно и что-то сильно лучше придумать.
источник

J

J in OpenStack — русскоговорящее сообщество
Но пока руки не дошли.
источник

VV

Vyacheslav Vershinin in OpenStack — русскоговорящее сообщество
грубо говоря пока у сервера все ядра не в полке у клиента не будет steal time?
источник

J

J in OpenStack — русскоговорящее сообщество
Ага.
источник

J

J in OpenStack — русскоговорящее сообщество
Но это грубо.
На деле, конечно, возможно что ядро хоста будет субоптимально раскидывать потоки виртуалок по ядрам. Но на практике такого никогда не замечал.
источник

И

Илья | 😶 ☮️... in OpenStack — русскоговорящее сообщество
в некоторых случаях может быть
источник

И

Илья | 😶 ☮️... in OpenStack — русскоговорящее сообщество
если прям по некоторым ядрам проходит нагрузка в моменте, как оно фиксится- хз
источник

PL

Pavel Lyaschenko in OpenStack — русскоговорящее сообщество
еще как будет
источник

PL

Pavel Lyaschenko in OpenStack — русскоговорящее сообщество
более того, если переподписка будет космическая, то на хосте ты не увидишь полную загрузку ядер - там будет тупо скедуллер щелкать процессы, на хостовом цпу у тебя будет чет порядка 80%, а на виртушках будет ад и израель
источник

PK

Pavel Kolobaev in OpenStack — русскоговорящее сообщество
Мне опыт подсказывате что при любой загрузке st будет. потому что доступ к памяти на другом проце не может быть меньше чем за такт
источник

PL

Pavel Lyaschenko in OpenStack — русскоговорящее сообщество
а еще нума и контроллеры на разных сокетах, кеш мисс и прочие замечательные прелести свободного полета процессов по сокетам
источник

ЯI

Я и твой кот I.... in OpenStack — русскоговорящее сообщество
Такое ощущение, что тут нищехостеры с 1000-кратной переподпиской и кластерами в общаге из ноутбуков обсуждение ведут, а не уважаемые доны с кластерами на экзабайты оперативки и сотни тысяч сокетов.
источник

PL

Pavel Lyaschenko in OpenStack — русскоговорящее сообщество
хоспаде, весь рынок паблик иаса в СНГ включая все-все-все гипервизоры всех-всех-всех вендоров - примерно 2 тыщи стоек по 5квт на 2/3 пустых, а вы тут про экзабайты =)
источник

PL

Pavel Lyaschenko in OpenStack — русскоговорящее сообщество
ну мож промахнулся - данные не свежие уже у меня, пусть будет 3 тыщи
источник