Ubuntu в Proxmox: кэш памяти и настройка для MotionEye

Высокий Cached в Ubuntu на VM Proxmox — это чаще всего нормальный и ожидаемый результат: ядро Linux агрессивно использует свободную RAM под pagecache, а показатель MemAvailable (~77 ГБ) показывает, что памяти достаточно; принудительная очистка (sync; echo 3 > /proc/sys/vm/drop_caches) лишь временно освобождает кэш и снижает производительность. Чтобы решить проблему без постоянных «костылей», нужно настроить управление памятью на госте и хосте: включить ballooning и qemu‑guest‑agent, задать адекватный Minimum memory для VM, ограничить MotionEye через systemd/cgroups или Docker и, при необходимости, настроить KSM/параметры vm. Детальный план диагностики и шаги — ниже.

Содержание

• Почему Proxmox Ubuntu память остаётся закэшированной
• Как правильно настроить управление памятью Proxmox Ubuntu для MotionEye
• Очистить память Ubuntu: когда и как (не как костыль)
• Диагностика — что проверить прямо сейчас
• Пошаговый план действий — быстро и надёжно
• Источники
• Заключение

Почему Proxmox Ubuntu память остаётся закэшированной

Linux «съедает» свободную память под pagecache и считает это нормой: кэш ускоряет чтение/запись, и ядро освободит его мгновенно при реальной потребности. Поэтому строка Cached (~75 ГБ) сама по себе не означает утечку памяти — важнее значение MemAvailable (~77 ГБ), которое показывает, сколько RAM реально доступно для приложений.

Proxmox (GUI) и некоторые мониторинги могут отображать кэш как «используемую» память, что пугает — но это вопрос учёта, а не фактической нехватки RAM. См. обсуждение поведения ballooning/отчётов в ветке форума Proxmox: PVE showing high memory usage but VM is not.

Ещё одна распространённая причина: ballooning не может вернуть память хосту, если в настройках гостя Minimum memory равен Maximum. В таком случае «шариковый» драйвер не может сжать объём памяти гостя и кэш остаётся внутри VM — подробнее в обсуждении: RAM usage is not going down (VM cleared cache).

Итого: высокое Cached — нормальный симптом; но если хост реально испытывает нехватку памяти или Proxmox показывает “забитую” RAM — нужно настроить сотрудничество гостя и хоста (ballooning, guest agent), а также ограничить ресурсы тяжёлых процессов внутри гостя (MotionEye).

Как правильно настроить управление памятью Proxmox Ubuntu для MotionEye

Коротко: настроить взаимодействие хоста и гостя + контролировать память MotionEye. Ниже — подробности и команды.

1. Начните с фактов: сколько реально использует процесс motion?
   Ваш top показывает RES ≈ 743 MB для motion. Это значит — сам процесс занимает <1 ГБ, а не 75 ГБ. Большая часть — pagecache, и он доступен системе. Так что проблема — не обязательно утечка памяти процесса, а учет кэша и поведение ballooning.

2. Включите qemu-guest-agent в гостевой Ubuntu (обязательно для корректной работы ряда функций и лучшего взаимодействия с Proxmox):

• В госте:
• sudo apt update && sudo apt install -y qemu-guest-agent
• sudo systemctl enable --now qemu-guest-agent
• Проверьте статус: systemctl status qemu-guest-agent
  qemu-guest-agent не «освобождает» кэш сам, но даёт хосту более точную информацию о состоянии гостя и помогает корректно управлять ballooning.

3. Включите и правильно настройте ballooning (Proxmox host):

• В веб-интерфейсе Proxmox: выберите VM → Hardware → Memory → добавьте/проверьте Balloon device и задайте Minimum memory меньше Maximum memory (например, под ваши нужды — несколько ГБ как минимум для ОС + MotionEye). Если Minimum = Maximum — сжатие памяти не сработает.
• В госте можно проверить модуль шарикового драйвера: lsmod | grep virtio_balloon (подгрузить: sudo modprobe virtio_balloon).
  Balloning позволит хосту вернуть неиспользуемую память от гостя, когда это потребуется.

4. Ограничьте MotionEye/motion, чтобы он не занимал непредсказуемые объёмы:

• Если установлен как системная служба (обычно это motion или motioneye), примените systemd‑контроль ресурсов:
• sudo systemctl edit motion
  В открывшемся файле добавьте:

[Service]
MemoryAccounting=yes
MemoryMax=1G

• sudo systemctl daemon-reload
• sudo systemctl restart motion
  Это даст гарантию, что процесс не выйдет за допустимый предел. Проверьте имя службы командой systemctl status motion или systemctl status motioneye.
• Если вы используете Docker, запускайте контейнер с лимитом памяти:
• docker run --memory=2g --memory-swap=2g ... ccrisan/motioneye:latest
  Контейнеризация упрощает жёсткое ограничение ресурсов.

5. Проверьте настройки MotionEye (буферы, разрешение, fps):

• Уменьшение разрешения/частоты кадров и количества буферов снижает удерживаемую память. Посмотрите параметры framerate, width, height, stream_maxrate, pre_capture и т.п. в конфигурации motion/motioneye.

6. Если нужен дедуп (KSM) и более агрессивное высвобождение на хосте:

• На Proxmox включите KSM (Kernel Samepage Merging) для экономии памяти между виртуальными машинами: echo 1 | sudo tee /sys/kernel/mm/ksm/run и настройте параметры pages_to_scan/sleep_millisecs при необходимости. По умолчанию KSM стартует в условиях нехватки памяти; детали — обзор оптимизации памяти в Proxmox.
  KSM помогает только если у вас много похожих страниц в разных VM.

7. Если после удаления файлов внутри гостя хост всё ещё “видит” занятость — выполните fstrim (особенно на thin/SSD/ZFS):

• В госте: sudo fstrim -av
  На форуме встречается кейс, когда после fstrim -av и перезагрузки Proxmox корректно пересчитала использование памяти/диска: RAM Usage Ubuntu 20.04.

Очистить память Ubuntu: когда и как (не как костыль)

Стоит ли ставить cron с echo 3 > /proc/sys/vm/drop_caches? Нет — обычно не стоит. Это убирает pagecache/dentries/slab, но и уничтожает выигрыш в производительности: данные, которые могли быть быстро прочитаны из RAM, придётся читать с диска.

Если всё же нужно временно очистить кэш для отладки:

• sudo sync && sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
  Используйте это только как диагностический шаг или в редких сценах обслуживания. Подробно о назначении и видах очистки — статья с командами: Настройка ядра Linux — очистка кэша.

Диагностика — что проверить прямо сейчас

Быстрая шпаргалка команд и что они покажут:

• Общая картина памяти:

• free -h

• cat /proc/meminfo | egrep "MemTotal|MemFree|MemAvailable|Cached"

• Процессы по использованию RSS:

• ps aux --sort=-rss | head -n 15 — реально занимаемая RAM процессами.

• Проверить, не использует ли Motion tmpfs/ramdisk:

• mount | grep tmpfs

• df -h | grep tmpfs

• Проверить сервисы гостя:

• systemctl status qemu-guest-agent

• lsmod | grep virtio_balloon

• Посмотреть, куда пишет Motion и какие параметры:

• journalctl -u motion -n 200 или логи motion (/var/log/motion*)

• Уточнить конфигурацию VM на хосте:

• В GUI Proxmox: Hardware → Memory (Balloon device), Options → Minimum memory

• Через CLI: посмотрите qm config <VMID> (в Proxmox) для подтверждения настроек памяти.

• (Опционально) изучить распределение страниц по процессам:

• pmap -x <pid> — карта памяти процесса.

Эти проверки обычно быстро покажут: реальная нагрузка process‑level или же классическая страница кэша.

Пошаговый план действий — быстро и надёжно

1. Убедитесь, что проблема — отображение кэша, а не OOM:

• free -h → если MemAvailable ≫ реальной потребности — тревоги нет.

2. Установите и включите qemu-guest-agent в госте:

• sudo apt update && sudo apt install -y qemu-guest-agent
• sudo systemctl enable --now qemu-guest-agent

3. В Proxmox добавьте balloon device и установите Minimum memory меньше Maximum:

• Через GUI: VM → Hardware → Add → Balloon Device; VM → Options → Minimum memory = N GB.
• После изменения проверьте, что модуль в госте загружен: lsmod | grep virtio_balloon.

4. Ограничьте MotionEye:

• Через systemd (пример 1G лимита):
• sudo systemctl edit motion → добавить:

[Service]
MemoryAccounting=yes
MemoryMax=1G

• sudo systemctl daemon-reload && sudo systemctl restart motion
• Или контейнеризируйте/запустите в Docker с --memory.

5. Проверьте и измените, если нужно, параметры I/O и tmpfs:

• Убедитесь, что Motion не хранит тонны данных в tmpfs; перенесите временные файлы на диск.

6. Только при необходимости: включите KSM на хосте и отрегулируйте:

• echo 1 | sudo tee /sys/kernel/mm/ksm/run
• (тюнинг: pages_to_scan, sleep_millisecs)

7. Не используйте drop_caches регулярно; вместо этого:

• Наблюдайте. Если нужно кратковременно очистить кэш для теста: sudo sync && sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

8. Мониторинг:

• Настройте простые оповещения на Proxmox (Datacenter → Metrics) и следите за Swap, OOM и Load. Если swap активно используется — это уже повод менять swappiness/память.

Если после всех шагов хост всё равно «не видит» освобождённой памяти — сделайте fstrim -av в госте и перезагрузку VM как диагностический шаг (в одном из обсуждений это помогло): RAM Usage Ubuntu 20.04.

Источники

1. https://forum.proxmox.com/threads/pve-showing-high-memory-usage-but-vm-is-not.113463/
2. https://forum.proxmox.com/threads/ram-usage-ubuntu-20-04.113374/
3. https://forum.proxmox.com/threads/ram-usage-is-not-going-down-vm-cleared-cache.90043/
4. https://github.com/home-assistant/operating-system/issues/2999
5. https://github.com/motioneye-project/motioneye/issues/2131
6. https://www.reddit.com/r/Proxmox/comments/1mk69rf/excessive_memory_usage_on_proxmox_9/?tl=ru
7. https://habr.com/ru/companies/otus/articles/566970/
8. https://bafista.ru/optimizacziya-operativnoj-pamyati-v-proxmox/

Заключение

В двух словах: высокое Cached на Ubuntu в VM Proxmox — обычно не баг, а фича ядра; MemAvailable показывает, что памяти много и всё доступно. Решение без «костылей» сводится к трём вещам: обеспечить корректное взаимодействие гостя и хоста (qemu‑guest‑agent + ballooning), ограничить ресурсы MotionEye (systemd/cgroups или Docker), и — опционально — настроить KSM/trim/параметры vm. Только после этих шагов ручная периодическая очистка кэша перестанет быть «необходимостью», и система будет вести себя предсказуемо.