Я использую контейнеры LXC в течение нескольких лет и недавно расширил типы приложений, которые работают внутри контейнерных сред.
Я начинаю ограничивать ресурсы на уровне контейнера с такими параметрами конфигурации, как:
lxc.cgroup.cpuset.cpus = 16-23
lxc.cgroup.memory.limit_in_bytes = 30720M
lxc.cgroup.memory.memsw.limit_in_bytes = 32768M
Я работаю с разработчиком, который использует инструмент "настройки" (pgtune) для создания конфигурации для базы данных Postgres, которая будет работать в среде LXC. Этот инструмент более старый и не совсем поддерживает виртуальные машины или контейнеры. Он дает рекомендации по размеру на основе ОЗУ, видимой системе.
Именно тогда я понял, что видимость всей оперативной памяти хост-системы (96 ГБ) для экземпляра контейнера в некоторых случаях может быть опасной.
Есть ли обходной путь для этого, или это просто данность при использовании LXC?
В настоящее время proc файловая система не поддерживает контейнер в пространствах имен монтирования, поэтому инструменты, основанные на этой логике, будут получать значения, связанные с хостом, а не с контейнерами.
Но работа в разработке, она называется lxc-fs и несколько выпусков доступна здесь. Это обходной путь в пространстве пользователя, который сделает возможным монтирование привязки через /proc чтобы добиться согласованности внутри контейнера.
Кажется, нет никакого способа обойти это. LXC использует cgroups для ограничения ОЗУ, а инструменты, не поддерживающие виртуализацию, читают статистику, например /proc/meminfo который не содержится в LXC и выводит всю оперативную память системы. Вы можете увидеть это поведение с помощью free или top а также при запуске внутри контейнера.
Источник: http://fabiokung.com/2014/03/13/memory-inside-linux-containers/