Еще одной, часто используемой тонкой настройкой LXC являются лимиты использования памяти. Но перед тем, как переходить непосредственно к настройкам разберем некоторые особенности использования памяти контейнерами.
В отличие от виртуальных машин, которые имеют выделенные ресурсы, контейнеры работают с общей памятью хоста и их аппетиты регулируются лимитами. Для системы контейнер ничем не отличается от любого другого приложения и точно также конкурирует за память на общих основаниях.
Т.е. если мы «выделили» контейнеру 16 ГБ памяти, но просит он только 4 ГБ, то он получит только запрашиваемое, а остальные 12 ГБ будут доступны другим процессам. Это позволяет гибко настраивать выделение памяти, когда суммарно лимиты могут превышать доступный объем.
Это нормально, допустим мы знаем, что наше рабочее приложение в среднем потребляет 2 ГБ памяти, но при пиковых нагрузках может попросить 3 - 3,5 ГБ, поэтому смело ставим лимит на 4 ГБ и, если в системе есть свободная память – контейнер ее получит.
А вот тут начинается самое интересное – лимиты. Их четыре. Они отвечают за верхние и нижние значения. Начнем с верхних. В конфигурационных файлах Proxmox
/etc/pve/lxc/nnn.conf (где nnn – ID контейнера) указывается просто выделенный объем памяти, а вот если мы заглянем в настоящий конфиг LXC в /var/lib/lxc/nnn/config, то увидим там две директивы (для контейнера с 4 ГБ памяти):lxc.cgroup2.memory.max = 4294967296
lxc.cgroup2.memory.high = 4261412864
▫️ lxc.cgroup2.memory.max – это жесткое верхнее ограничение по памяти в байтах, ничего сверх указанного значения контейнер не получит.
▫️ lxc.cgroup2.memory.high – мягкий верхний лимит, Proxmox устанавливает его на уровне 99% жесткого лимита. При его достижении система начинает агрессивно вытеснять память, сбрасывать кеш и, если ничего не поможет, задействует OOM Killer.
Данный зазор – в 1% - это есть защитный промежуток, чтобы контейнер вдруг внезапно не уперся в жесткий лимит, что будет означать, что память для него закончилась. Но стандартные Linux механизмы ему не помогут, так как он считает доступной всю память хоста.
Таким образом memory.high как раз включает защитные механизмы и начинает активно освобождать память.
Чем нам может помочь этот лимит? Для второстепенных контейнеров мы можем его понизить. Для нашего примера, когда для пиковой нагрузки в 3,5 ГБ мы поставили жесткий лимит 4 ГБ, то мягкий можем сделать как раз 3,5 ГБ.
Если контейнер превысит это значение, то он начнет сначала свопить, потом сбрасывать кеш. Т.е. просядет в производительности, но конкурировать за память с более важными соседями не будет.
Теперь перейдем к нижним лимитам, это:
lxc.cgroup2.memory.low
lxc.cgroup2.memory.min
▫️ lxc.cgroup2.memory.min – это нижний жесткий лимит гарантированной памяти контейнера. Фактически мы забираем объем, указанный в этой директиве из общего пула, и закрепляем за контейнером, даже если он ее всю не утилизирует.
Скажем вы выделили 1 ГБ, а контейнер использует всего 256 МБ, но оставшийся резерв не будет доступен никакому другому процессу, так как закреплен за определенным контейнером. Поэтому использовать эту опцию надо осторожно, так как можно серьезно повлиять на стабильность и производительность всей системы.
▫️ lxc.cgroup2.memory.low – это мягкий нижний предел, который система выделяет контейнеру в приоритетном порядке, но, при необходимости, эта память может быть использована или вытеснена другими процессами.
В данном случае система не жестко фиксирует, а защищает выделенный объем памяти от вытеснения.
Если у нас есть несколько контейнеров с различными значениями memory.low и свободной памяти недостаточно на удовлетворение всех лимитов, то она будет распределена пропорционально значениям memory.low.
Основное отличие от memory.min здесь в том, что если памяти не хватает, то ее не хватает всем, но некоторым ее не хватает чуть меньше, чем остальным. Это позволяет поддерживать систему стабильной, пусть и ценой некоторой потери производительности.