Сколько RAM нужно для Mealie

MAATRIX

Mealie выглядит легковесным приложением — менеджер рецептов с планированием меню и списком покупок, ничего похожего на CRM или почтовый сервер. Но именно поэтому люди недооценивают его аппетит: ставят на VPS с 512 МБ «на посмотреть» и получают зависший интерфейс или OOM-killer в логах в первый же вечер, когда пробуют импортировать полсотни рецептов из интернета. Разберём, сколько памяти реально нужно Mealie на разных стадиях — от одиночного теста до семьи из пяти человек с общим списком покупок.

Из чего складывается потребление памяти Mealie

Mealie — это связка из трёх процессов, и RAM расходуется не одним монолитным блобом, а по слоям:

• Backend (FastAPI + Python) — держит бизнес-логику, парсинг рецептов, генерацию списков покупок, работу с изображениями. Это основной потребитель памяти в состоянии простоя.
• База данных — по умолчанию SQLite, встроенная в тот же контейнер, почти не тянет отдельной памяти. Если вы переключились на PostgreSQL (актуально для нагруженных инстансов), добавляется отдельный процесс со своим пулом соединений.
• Frontend (Nuxt/Vue) — в готовом Docker-образе отдаётся статикой через тот же backend, дополнительной оперативки почти не просит, вся тяжесть на стороне браузера клиента, а не сервера.

Основной скачок потребления памяти происходит не в режиме ожидания, а во время двух операций: импорт рецепта по URL (парсер скачивает страницу, разбирает HTML, тянет и обрабатывает изображение) и массовый импорт (когда вы заливаете десятки рецептов через API или скрипт разом). В простое Mealie почти незаметен, под нагрузкой на короткое время может дать всплеск в 2-3 раза выше базового уровня.

Официальный минимум и что происходит на его границе

Разработчики Mealie в документации называют ориентир 512 МБ RAM как минимум и рекомендуют 1 ГБ для комфортной работы. Это честная цифра для голого запуска — контейнер стартует и отвечает на запросы. Но на практике 512 МБ — это память, при которой:

• Импорт одного рецепта по ссылке иногда проходит, иногда падает с таймаутом, если страница донора тяжёлая (много картинок, встроенная реклама, JS-рендер).
• Если на том же сервере крутится ещё и обратный прокси (Nginx, Caddy, Traefik) и пара фоновых контейнеров — margin съедается моментально, ядро Linux начинает убивать процессы через OOM-killer, и первым чаще всего гибнет именно Python-процесс Mealie, а не прокси.
• Загрузка своих фото к рецептам (не по ссылке, а руками) с телефона в оригинальном разрешении 8-12 МБ на снимок — заметно замедляет отклик, потому что обработка изображения происходит в памяти процесса.

512 МБ подходит только если Mealie — единственный сервис на сервере и вы используете его умеренно: несколько рецептов в неделю, без агрессивного импорта. Если вы читаете эту статью потому что уже столкнулись с зависаниями — почти наверняка дело в нехватке памяти, а не в багах приложения; общий разбор симптомов и способов диагностики есть в статье что делать при нехватке RAM.

Реальные сценарии использования и память под них

Дальше — не измеренные бенчмарки (Mealie не даёт официальной методики нагрузочного тестирования, а результаты сильно зависят от объёма БД и частоты импорта), а ориентировочная раскладка по паттернам использования, основанная на архитектуре приложения и опыте эксплуатации похожих Python/FastAPI сервисов. У вас цифры могут отличаться на 20-30% в любую сторону.

Ключевой момент — размер базы данных сам по себе почти не влияет на память в режиме простоя (SQLite читает данные с диска по запросу, а не держит всё в RAM), но влияет на пиковую нагрузку при поиске и фильтрации по большой коллекции рецептов: чем больше записей, тем больше временных структур в памяти при сложном запросе.

Docker Compose с лимитами памяти

Разумно с самого начала ограничить контейнер, а не давать ему съесть всю память сервера в случае утечки или зависшего импорта. Рабочий вариант compose-файла с явными лимитами:

services:
  mealie:
    image: ghcr.io/mealie-recipes/mealie:latest
    container_name: mealie
    restart: unless-stopped
    ports:
      - "9925:9000"
    deploy:
      resources:
        limits:
          memory: 1g
        reservations:
          memory: 512m
    volumes:
      - mealie-data:/app/data/
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Moscow
      - BASE_URL=https://recipes.example.com
      - MAX_WORKERS=1
      - WEB_CONCURRENCY=1

volumes:
  mealie-data:

Обратите внимание на MAX_WORKERS и WEB_CONCURRENCY — по умолчанию Mealie может поднять несколько воркеров Gunicorn/Uvicorn, и каждый добавляет свой базовый расход памяти (грубо 100-150 МБ на воркер сверх основного процесса). На сервере с 1-2 ГБ RAM держите один воркер — для семейного использования пропускной способности хватает с запасом, а память экономится ощутимо.

Если deploy.resources.limits не работает у вас (это ограничение Docker Swarm-режима, в обычном docker compose up без Swarm лимиты через deploy могут игнорироваться в старых версиях Compose) — используйте прямой синтаксис через mem_limit:

services:
  mealie:
    image: ghcr.io/mealie-recipes/mealie:latest
    mem_limit: 1g
    mem_reservation: 512m
    memswap_limit: 1g

Когда переходить с SQLite на PostgreSQL — и что это меняет для памяти

По умолчанию Mealie хранит данные в SQLite-файле внутри volume — это нормально для одной семьи или небольшой группы. Официально поддерживается и PostgreSQL, и переключение имеет смысл, если:

• Инстансом пользуются несколько независимых семей/групп одновременно (общий Mealie на дом/офис/коворкинг).
• Вы видите блокировки при одновременной записи (SQLite блокирует базу целиком на запись, при параллельных импортах это заметно).
• Хотите вынести БД на отдельный сервер для резервного копирования и снапшотов без остановки Mealie.

PostgreSQL добавляет отдельный процесс с собственным потреблением памяти — минимально можно ужать shared_buffers до 64-128 МБ для такой лёгкой нагрузки, но реалистичный бюджет на PostgreSQL под Mealie — ещё 256-512 МБ сверх самого приложения. Итоговый план на связку Mealie + PostgreSQL на отдельном VPS — от 2 ГБ RAM, чтобы не упираться в лимиты при импорте и одновременных сессиях.

services:
  mealie:
    image: ghcr.io/mealie-recipes/mealie:latest
    environment:
      - DB_ENGINE=postgres
      - POSTGRES_USER=mealie
      - POSTGRES_PASSWORD=change_me
      - POSTGRES_SERVER=postgres
      - POSTGRES_PORT=5432
      - POSTGRES_DB=mealie
    depends_on:
      - postgres

  postgres:
    image: postgres:16-alpine
    environment:
      - POSTGRES_USER=mealie
      - POSTGRES_PASSWORD=change_me
      - POSTGRES_DB=mealie
    mem_limit: 512m
    volumes:
      - postgres-data:/var/lib/postgresql/data

volumes:
  postgres-data:

Как проверить реальное потребление на своём сервере

Не верьте таблицам выше на слово — проверьте на своих данных, это займёт пять минут:

# Живое потребление контейнера в реальном времени
docker stats mealie

# Разовый снимок с точными цифрами
docker exec mealie cat /sys/fs/cgroup/memory.current

# Общая картина по серверу — сколько свободно, сколько в swap
free -h

Отдельно стоит понаблюдать за docker stats во время импорта 5-10 рецептов подряд по ссылкам — именно этот пик покажет ваш реальный потолок, а не цифру в режиме простоя. Если во время теста видите, что used память подбирается к лимиту контейнера ближе чем на 15-20%, — берите план на ступень выше сразу, не дожидаясь падения под нагрузкой в обычный день.

Полезно так же настроить swap как страховку на случай кратковременного всплеска — это не решает проблему нехватки RAM системно, но спасает от мгновенного OOM-killer при разовом пике:

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Соседство с другими сервисами: не считайте Mealie в вакууме

Mealie редко живёт на сервере в одиночестве — рядом обычно крутится обратный прокси с TLS-терминацией, может быть Watchtower для автообновлений образов, иногда Nextcloud или Home Assistant по соседству в рамках домашней инфраструктуры. Каждый такой сосед добавляет свой базовый расход, и считать нужно сумму, а не Mealie отдельно:

• Nginx/Caddy/Traefik — 50-150 МБ в зависимости от количества проксируемых хостов.
• Watchtower — около 20-30 МБ, минимальная добавка (подробнее о его настройке и типичных ошибках — в статье про автообновление Watchtower на сервере).
• Nextcloud рядом — совсем другой калибр памяти, см. отдельный разбор сколько RAM нужно для Nextcloud.
• Home Assistant рядом — тоже заметный сосед, смотрите сколько RAM нужно для Home Assistant.

Практическое правило: берите план VPS с запасом минимум в 30-40% сверх суммы базовых потребностей всех сервисов — это покрывает и файловый кэш ОС, и одновременные пики нескольких контейнеров.

Частые вопросы