ИИ
ага. это же обычные процессы qemu. они просто будут конкурировать за ресурсы ядра
Size: a a a
2019 March 08
AZ
vCPU может быть больше чем потоков на хосте. У меня в проде на Варе соотношение почти 1:5 уже.
AZ
И это как бы норма если утилизация CPU в норме.
k
ага. это же обычные процессы qemu. они просто будут конкурировать за ресурсы ядра
это точно, но их же можно как-то ограничивать, вот cgroups как раз для этого и используются
ИИ
это точно, но их же можно как-то ограничивать, вот cgroups как раз для этого и используются
ага. только cgroups не ограничивают cpu, а выставляют приоритеты.
пока нет конкуренции за ресурсы, числа оттуда не имеют смысла
пока нет конкуренции за ресурсы, числа оттуда не имеют смысла
k
ага. только cgroups не ограничивают cpu, а выставляют приоритеты.
пока нет конкуренции за ресурсы, числа оттуда не имеют смысла
пока нет конкуренции за ресурсы, числа оттуда не имеют смысла
Ну по сути если не давать возможности к overselling, то есть не присваивать отрицательные значения RESERVED_CPU хоста, то все должно быть по чесному. Даже если хост будет на 100% заполнен, каждая виртуалка получит cpu-time исходя из своих приоритетов, то есть значения CPU установленного в OpenNebula и транслированного в cpu shares.
k
В случае если хост заполнен не полностью, каждая виртуалка получает бонус в виде дополнительного cpu time, которое она может заюзать, равное количеству физических ядер хоста кратное числу vCPU виртуалки
ИИ
Ну по сути если не давать возможности к overselling, то есть не присваивать отрицательные значения RESERVED_CPU хоста, то все должно быть по чесному. Даже если хост будет на 100% заполнен, каждая виртуалка получит cpu-time исходя из своих приоритетов, то есть значения CPU установленного в OpenNebula и транслированного в cpu shares.
ага. я думаю, просто выставить всем виртуалкам 0.01 cpu и набить ими сервер)
у всех будет равное число в cgroups
у всех будет равное число в cgroups
k
ага. я думаю, просто выставить всем виртуалкам 0.01 cpu и набить ими сервер)
у всех будет равное число в cgroups
у всех будет равное число в cgroups
хм, а это годный workaround :)
ИИ
opennebula следит за реальной нагрузкой в REAL_CPU. вот буду на него ориентироваться
k
по сути нужно опцию чтобы через cgroups выставлять не shares а cpu-time, чтобы избежать таких хитрецов
k
ага. я думаю, просто выставить всем виртуалкам 0.01 cpu и набить ими сервер)
у всех будет равное число в cgroups
у всех будет равное число в cgroups
кстати опять же не сработает, если хост заполнен другими виртуалками, с нормальным cpu
ИИ
а я всем выставлю
ИИ
для dev окружения самое то)
k
я просто смотрю на это с точки зрения public cloud провайдера, и мне главное что бы ты своей кучкой виртуалок с CPU=0.01 не навредил остальным customers
ИИ
а, это да.
у меня private cloud для сотен dev виртуалок, которые почти не используются. для этого это подойдет.
для прода, наверное, лучше оставить cpu=vcpu
у меня private cloud для сотен dev виртуалок, которые почти не используются. для этого это подойдет.
для прода, наверное, лучше оставить cpu=vcpu
2019 March 12
O
а, это да.
у меня private cloud для сотен dev виртуалок, которые почти не используются. для этого это подойдет.
для прода, наверное, лучше оставить cpu=vcpu
у меня private cloud для сотен dev виртуалок, которые почти не используются. для этого это подойдет.
для прода, наверное, лучше оставить cpu=vcpu
Общепринятый тренд cpu=0.5 vcpu на проде. Там оверселинг около 100% обычно. По крайней мере я сталкивался именно с этими цыфрами.
O
Если я правильно понимаю, то vcpu это не жестакая инструкция для cgroups. Словом приоритет исполнения а не ограничение мощностей
ИИ
Omfg
Если я правильно понимаю, то vcpu это не жестакая инструкция для cgroups. Словом приоритет исполнения а не ограничение мощностей
vcpu - это как раз количество ядер.
а cpu - приоритет.
если на хосте у всех виртуалок будет cpu=0.5, это будет давать такой же эффект, что и cpu=1, или cpu=100
а cpu - приоритет.
если на хосте у всех виртуалок будет cpu=0.5, это будет давать такой же эффект, что и cpu=1, или cpu=100