Привет. У тебя нет фиксированного числа единиц (=долей), думай о них как о приоритетах: например, если у тебя есть 3 контейнера (A, B и C) и ты назначаешь контейнеру A 500 долей, контейнеру B 250 долей и контейнеру C 100 долей. Это значит, что A может получить в 5 раз больше CPU, чем контейнер C, и в 2 раза больше, чем контейнер B. Нет каких-либо общепринятых практик, так как все зависит от конкретного случая. Лучше всего установить их под свои нужды. Если ты хочешь, чтобы все контейнеры получали равное время CPU, установи им одинаковое значение (т.е. ничего не меняй, так как это значение по умолчанию). Если у тебя есть контейнер, в котором работает важный сервис, возможно, стоит дать ему немного больше. Нам также очень приятно, если пользователь вносит свой вклад в PVE Wiki, это было бы замечательно! Хотя мы также стараемся расширять его сами, естественно. КСТАТИ: "vzcpucheck" больше не работает, так как это был инструмент OpenVZ, а PVE4 перешел с OpenVZ на LXC.

Вы можете просто использовать KVM, если хотите полную виртуализацию. На мой взгляд, ограничение по процессору работает отлично, и нет реальной причины ограничивать количество видимых ЦП для контейнеров.

Я не согласен, Дитмар. Когда контейнеры продаются как VPS, должна быть четкая информация о ресурсах ЦП для клиентов. Если они увидят 8 ядер после покупки VPS с одним ядром, у них не будет стимула для обновления, несмотря на то, что cpulimit ограничит их фактическую долю процессорных ресурсов. Поэтому, если возможно, я хотел бы предложить, чтобы контейнеры LXC работали так же, как контейнеры OpenVZ: отображали только количество процессоров, доступных для контейнера.

Дитмар, насколько мне известно, когда LXD станет стабильным, он будет работать именно так, с возможностью ограничивать IOPS (когда это будет готово). Есть ли планы по интеграции LXD и с ним LXC 2.0?

Дитмар, я не уверен насчёт LXD, но Ubuntu предоставляет нужную функциональность через lxcfs: https://insights.ubuntu.com/2015/03/02/introducing-lxcfs/ https://linuxcontainers.org/lxcfs/ Вот страница на GitHub: http://github.com/lxc/lxcfs

В таком случае, не могли бы вы включить привязку файлов заменяемого /proc, чтобы показать фактическое количество процессоров (ограничение по CPU) и размер свопа, доступный контейнеру?

Спасибо за информацию. Проблема в том, что назначение конкретных ядер контейнерам серьезно нарушит справедливое распределение ресурсов на хосте. Поскольку невозможно предсказать, сколько нагрузки один контейнер создаст на конкретном ядре, будет очень трудно равномерно распределить доступные ядра между контейнерами, что, скорее всего, приведет к перегрузке некоторых ядер (в то время как другие останутся без нагрузки). OpenVZ действительно обеспечивал перевод между запланированным временем CPU на хосте и виртуальными ядрами в госте, так что если вы назначали 2 ядра контейнеру, то можно было точно видеть, сколько нагрузки они имели, глядя на это в госте. Надеюсь, кто-нибудь сделает это для lxcfs.

Здравствуйте, те же проблемы: - Ограничение ядра в контейнере - Хранение контейнера сохранено как .raw вместо папки - Невозможность уменьшить размер хранилища контейнера на fl Есть ли трекер ошибок? Спасибо