Практическое количество одновременных лимитов LXC на одном узле
Существуют ли какие-либо практические ограничения на количество одновременных контейнеров LXC, запускаемых на одном компьютере?
Очевидно, что это зависит от спецификации узла (cpu, ram, ..), но на самом деле меня интересует стоимость запуска процесса непосредственно в операционной системе OS против запуска того же процесса в выделенном контейнере на том же коробка? Если вам нужно поставить цифру в неслыханную разницу, что это за накладные расходы? Это хороший способ выяснить максимальное количество контейнеров lxc, которое вы должны запускать на одном сервере?
2 ответа
Накладные расходы очень малы, и вы можете запустить очень большое количество контейнеров, которые ничего не делают, но это также не было бы очень интересно. Сколько полезных контейнеров вы можете запустить в вашей системе, зависит от того, как вы определяете полезные. Вам придется проверить реальные варианты использования и посмотреть.
Одним из практических ограничений, однако, является количество разрешенных пид. Вы можете увидеть это, посмотрев на /proc/sys/kernel/pid_max. Но это, вероятно, бесполезное число по причинам, изложенным выше.
Как было сказано выше, накладные расходы минимальны. Переключение пространств имен обычно происходит без издержек (эти поля уже существуют даже для хост-процессов), поэтому основные издержки возникают из-за нескольких дополнительных ресурсов, которые должны быть созданы LXC, обычно 4-5 bind-mounts, возможно, несколько монтирований tmpfs два устройства VETH и устройство с обратной связью.
Поскольку библиотеки, как правило, совместно используются контейнерами, даже запуск init и куча других процессов не требуют таких больших ресурсов.
Все это говорит о том, что довольно сложно ответить на ваш вопрос :) Если вы возьмете один процесс и сравните его, работающий на хосте или в контейнере, накладные расходы для этого конкретного процесса будут равны 0. Фактические накладные расходы LXC исходит из родительского процесса и дополнительных ресурсов, которые процесс может использовать (сетевые устройства, ...).
Как бы то ни было, в последнее время я не проводил никаких сумасшедших тестов, но несколько месяцев назад мне удалось запустить около тысячи простых контейнеров apache2 в комплекте с системой инициализации на простой коробке Pentium4 с 4 ГБ оперативной памяти. Эти контейнеры делят свои rootfs, чтобы оптимально использовать разделяемую память, но, тем не менее, все началось нормально.
О, и что касается предела pid_max, это не совсем предел, так как в настоящее время он может быть увеличен до 2 ^ 64 (по крайней мере, в 64-битных системах), поэтому предел 32768 - это что-то в прошлом.