Процессорное время имеется ввиду?

грубо говоря, да. в cgroups параметр cpu shares

То есть по этой картинке значит что ресурсов процца выделил почти 60%? а по факту кластер не чем не занимается, нагрузки на вируталках нет?

Да, это просто для честного хостера

Я провел исследования, сделал выводы и хочу с вами поделиться.
У виртуалки в opennebula есть два параметра: CPU и VCPU.
И они значат не то, что вы думаете.

VCPU - это сколько ядер в виртуалке.
А ещё это - сколько ядер хоста может выжрать виртуалка.
Одно ядро виртуалки, если его нагрузить, выжирает одно ядро хоста.
Виртуалка с 4 VCPU, если их загрузить, нагрузит 4 ядра хоста.

CPU - бесполезный параметр.
opennebula позволяет выставлять приоритеты виртуалкам по части cpu.
Приоритеты выставляются через подсистему cgroups.
В cgroups есть параметр cpu.shares, который можно выставить процессу или группе процессов.
Два процесса с cpu.shares=100 поделят процессорное время ядра поровну.
Процессы с 100 и 200 поделят время, как 1/3 и 2/3 (каждый получит свой кусок от 100+200).
Так вот, CPU=1 у виртуалки просто выставляет ей cpu.shares=1024. И все.
CPU=0.5 - это cpu.shares=512.
CPU=0.01 - это cpu.shares=11.

Как это будет выглядеть на практике.
Допустим, есть хост с 1 ядром.
И мы запускаем 2 виртуалки с такими параметрами:

* v1: CPU=1 VCPU=1
* v2: CPU=1 VCPU=1

Если на v1 и v2 запустить нагрузку, они поделят одно реальное ядро пополам.
Если у v1 указать CPU=0.5, то он будет получать 33% одного реального ядра, а v2 - 66%.
Почему? Потому что их cpu.shares будут равны в сумме 1536. Доля v1 (512) в этом будет 33%, а доля v2 (1024) - 66%.
Так вот, если теперь у v2 указать CPU=0.5, то они снова будут делить ядро пополам.
Почему? 512+512 = 1024, и доля каждого (512) будет снова равна 50%.

CPU не отражает что-то сам по себе.
Он просто задает приоритет.
И он имеет смысл только в сравнении с CPU других виртуалок.
CPU=1 у всех виртуалок на хосте имеет такой же смысл, как CPU=0.01 или CPU=100.
Он имеет смысл только в одном случае: если у нас честный хостинг.
Т.е. если мы продаем виртуалки вообще без overselling'а.
Например, сервер на 24 ядра - это 24 виртуалки с одним виртуальным ядром.
Честно и не выгодно.
В этом случае параметр можно использовать.
opennebula честно считает отданные CPU и указывает их в "Allocated CPU".

вот старое сообщение

Ладно у меня вопрос на самом деле другой был, что такое 2400 😅 чтоза значение

Спасибо! щас вникну

одно ядро cpu - это 100.
2400 - это 24 ядра.
при создании виртуалки можно указать 0.01 ядра - это будет 1

Понял спасибо, у меня три хоста по 8 ядер 👍

Народ, здравствуйте. Ни у кого не было проблем при переходе на 5.10 с и при обновлении linstor'а? Никак не может исполнить данную команду,  все привелегии на действия в var/lib/one/remotes/tm oneadmin'у предоставил.

Датастор просто в полном угнетении)

Ребят ктонить ELK юзает? сколко стоит лецензии на "Elastic on-prem" ? и ваще стоит покупать?
А то впичатления приятные, а так че не ткни все "Please upgrade your license".

Или пните меня в чат по теме если есть такие =)))

Эээ, зачем лицуха?

Используем в кластере с 3мя дата нодами. Ранее задумывались о покупки т.к. не было security plugins. сейчас с 6.8 такая фича есть в бесплатной лицензии (там какой то скандал был, что данные утекли и вытащили в опенсорс). Амазон свой форк на основе oss версии сделали и там свой security fork https://opendistro.github.io/for-elasticsearch/

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

о покупки лицензии даже не задумывались что то.