Перенес стэк с VM в LXC, все завелось как и в VM, поэтому смело можно ставить в LXC.
Единственный нюанс после переноса, в логах есть:
create_uring failed: falling back to libaio в MariaDB — возникает почти всегда, если машина крутится в LXC или на ядре, где для контейнеров ограничены системные вызовы io_uring. База сама автоматически и безболезненно переключилась на классический движок асинхронного ввода-вывода libaio. На стабильность это не влияет.WARNING Memory overcommit must be enabled! в Redis — стандартное «ворчание» Redis на настройки ядра Linux хоста. На домашних инстансах ни на что не влияет. Если захочешь убрать, достаточно на самой новой хост-машине (не в контейнере) выполнить sudo sysctl vm.overcommit_memory=1
В контейнере команду выполнить не даст, нужно делать на хосте, но в таком случае она будет действовать на все контейнеры.
Цитата из Ai на этот счет:
Если коротко: в 95% случаев в домашних лабораториях это никак не вредит системе, но поведение оперативной памяти для разных типов машин изменится по-разному.
Давай разберем подробно, что произойдет с твоими сервисами.
1. Как это скажется на LXC-контейнерах (Эффект прямой)
Поскольку все LXC-контейнеры делят одно ядро с Proxmox, эта настройка автоматически применится ко всем контейнерам без исключения.
-
Плюсы: Если у тебя в других контейнерах крутятся базы данных (PostgreSQL, MySQL, MariaDB) или другие инстансы Redis, им тоже станет «дышать» легче. Они перестанут спотыкаться на операциях типа fork() при создании бэкапов.
-
Минусы: Снимается внутренний предохранитель ядра. Если какой-то процесс в любом контейнере решит бесконечно жрать память (например, из-за утечки памяти в скрипте), ядро Linux не откажет ему на старте, а будет выделять память до последнего.
Почему это НЕ приведет к катастрофе?
В Proxmox для каждого контейнера в разделе Resources жестко задан лимит оперативной памяти (Memory) и свопа (Swap). За этим следит механизм ядра под названием cgroups.
Даже если внутри контейнера включен безлимитный оверкоммит, Proxmox жестко ударит контейнер по рукам, как только тот попытается выйти за рамки выделенных ему, например, 2 ГБ. За рамки своего контейнера прожорливый процесс не уйдет.
2. Как это скажется на виртуальных машинах (KVM) (Эффект изолированный)
С полноценными виртуалками ситуация другая. У каждой VM есть свое собственное, полностью изолированное ядро Linux или Windows.
-
Глобальный параметр vm.overcommit_memory=1 на хосте Proxmox означает лишь то, что хост всегда разрешит процессу qemu (который и есть твоя виртуалка) запрашивать память у гипервизора.
-
Внутри самой VM ничего не изменится. Если внутри виртуалки стоит стандартный режим 0, то процессы внутри нее будут жить по старым правилам. Чтобы включить оверкоммит в VM, его нужно прописывать внутри нее отдельно (как мы пытались сделать в начале).
Главный и единственный риск: Что будет, если физическая память ПРАВДА закончится?
Если ты выделил контейнерам слишком много памяти (сделал оверпровижининг — например, на хосте 16 ГБ RAM, а контейнерам суммарно раздал 24 ГБ) и они одновременно решат ее занять, наступит критическая ситуация.
Когда физическая память и swap на Proxmox закончатся физически, ядро больше не сможет выделять страницы памяти. В этот момент включится OOM Killer (Out Of Memory Killer) самого Proxmox.
Ядро начнет экстренно завершать процессы, чтобы спаснить сам гипервизор от полного зависания. И вот тут логика выбора «жертвы» угадывается тяжело:
-
Он может «пристрелить» самый прожорливый процесс внутри любого LXC-контейнера (например, твой mariadbd).
-
В худшем случае он может решить, что виноват процесс qemu одной из виртуальных машин, и у тебя просто «потухнет» целая виртуалка.
Как спать спокойно? (Чек-лист для Proxmox)
Чтобы спать спокойно с включенным оверкоммитом, соблюдай три простых правила в Proxmox:
-
Не раздавай память «впритык»: Оставляй самому Proxmox хотя бы 1.5–2 ГБ свободной памяти под его нужды.
-
Настраивай лимиты: Никогда не оставляй контейнеры без ограничений по RAM в настройках Proxmox.
-
Включи Swap на хосте: Наличие хотя бы 4–8 ГБ свопа на SSD-диске хоста Proxmox дает ядру огромный запас времени, чтобы сбросить туда неактивную память и не активировать OOM Killer при резких скачках нагрузки.
Если на хосте отображается, что RAM занята, например, на 70-80% в пиках — включай эту настройку смело, никаких проблем с другими контейнерами не будет.