Сколько RAM нужно для Baïkal

MAATRIX

Если вы ищете, сколько памяти закладывать под Baïkal, скорее всего уже устали от Google Calendar с чужими рекламными трекерами или от Nextcloud, который для одной задачи синхронизации календаря и контактов явно избыточен. Baïkal — это как раз тот редкий случай, когда сервер можно поднять на минимальном VPS и забыть о нём на годы. Ниже — реальные цифры по памяти в зависимости от числа пользователей, СУБД и способа развёртывания, без надувания требований «про запас».

Что такое Baïkal и почему он такой лёгкий

Baïkal — это PHP-приложение поверх библиотеки sabre/dav, которое реализует протоколы CalDAV (календари) и CardDAV (контакты) плюс простую веб-панель администрирования. Никакого демона, никакого фонового процесса, который постоянно жуёт память — это обычное веб-приложение, которое просыпается на каждый HTTP-запрос от клиента (телефон, Thunderbird, DAVx5) и снова засыпает.

Именно поэтому Baïkal принципиально отличается по требованиям от того же Nextcloud: там крутится PHP-FPM с десятками модулей, preview-генератор, очереди фоновых задач, а здесь — минимальный набор: sabre/dav, PDO для базы, немного XML-парсинга. На голом PHP-FPM без базы Baïkal съедает 15-25 МБ на воркер — это в разы меньше, чем у Nextcloud, если вам нужен полноценный офисный комбайн, а не только календарь и контакты, о его развёртывании мы отдельно писали в статье про установку Nextcloud на VPS.

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

Реальный расход RAM на сервере с Baïkal — это не только сам PHP-процесс. Считать нужно всю связку:

• PHP-FPM воркеры — каждый активный воркер держит от 15 до 40 МБ в зависимости от числа PHP-расширений (pdo_sqlite/pdo_mysql, xml, mbstring, curl). При пуле из 4-5 воркеров это 80-200 МБ.
• Веб-сервер (nginx или Apache) — nginx в роли фронта перед PHP-FPM берёт 5-15 МБ базово плюс по 1-3 МБ на воркер-процесс. Apache с mod_php тяжелее и держит PHP прямо в своих процессах, из-за этого суммарный расход выше.
• База данных — если это SQLite, отдельного процесса нет вообще, база — это просто файл, который открывает PHP. Если это MySQL/MariaDB, добавляется процесс mysqld, который в простое держит 150-300 МБ (зависит от innodb_buffer_pool_size в конфиге).
• ОС и системные службы — на минимальном Ubuntu/Debian без графики это 100-200 МБ на ядро, systemd, cron, sshd.
• Кэш файловой системы — Linux сам займёт «свободную» память под дисковый кэш, это нормально и не считается утечкой, при нехватке она мгновенно освобождается под приложения.

Итого: чистый Baïkal с SQLite — это самая лёгкая связка, которую вообще можно представить для self-hosted CalDAV/CardDAV.

Минимальная конфигурация: 512 МБ

Для личного использования (1-3 аккаунта, несколько устройств на семью) хватает VPS с 512 МБ RAM. На этом объёме реально работают:

• Debian 12 или Ubuntu 24.04 minimal — около 120-150 МБ в простое;
• nginx + php8.3-fpm с пулом на 2-3 воркера — 60-100 МБ;
• Baïkal на SQLite — база в виде файла db.sqlite, отдельного процесса нет, только то, что заняли PHP-воркеры при открытии;
• swap 512 МБ-1 ГБ на всякий случай (не как постоянная память, а как страховка от редких пиков).

Оговорка сразу: 512 МБ — это конфигурация без запаса. Если на том же сервере вы захотите поставить что-то ещё (например, тот же n8n или личный сайт), память кончится быстро. Для отдельного изолированного сервера под один Baïkal это рабочий вариант, и мы регулярно видим такие связки живыми месяцами без перезагрузок по OOM.

Таблица: сколько RAM закладывать по сценарию

Цифры ниже — ориентир по практике эксплуатации подобных PHP+SQLite/MySQL стеков, у вас может отличаться в зависимости от числа установленных PHP-модулей и настроек пула FPM — считайте это отправной точкой, а не гарантией.

Ключевой момент в этой таблице — не число пользователей само по себе, а частота синхронизации их клиентов. Один пользователь с DAVx5, настроенным на sync каждые 15 минут, создаёт заметно больше кратковременных PHP-процессов в день, чем десять пользователей, синхронизирующихся вручную раз в сутки. Если у вас корпоративные телефоны с агрессивным push-sync — закладывайте на ступень выше, чем в таблице.

SQLite vs MySQL/MariaDB: что выбрать

Baïkal из коробки предлагает выбор БД при первой настройке через /admin/. Разница по памяти существенная:

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

MySQL/MariaDB — отдельный процесс mysqld, который добавляет постоянные 150-300 МБ даже без единого запроса. Плюсы: лучше держит параллельную нагрузку, привычнее для бэкапов через mysqldump, легче интегрируется, если у вас уже есть MySQL на сервере под другие проекты (тогда Baïkal просто заводит свою базу в существующем инстансе без прироста памяти на второй mysqld).

Практический вывод: если это выделенный сервер под один Baïkal и до полусотни пользователей — берите SQLite и не тратьте память на MySQL. Разворачивать MySQL имеет смысл, только если у вас уже есть база на сервере для других сервисов, или пользователей действительно много и параллельных запросов тоже.

Docker Compose и распределение памяти по контейнерам

Если разворачиваете через Docker (частый вариант — образ ckulka/baikal с вариантами -nginx или -apache), удобно сразу поставить лимиты памяти, чтобы контейнер не мог съесть больше, чем вы закладывали:

services:
  baikal:
    image: ckulka/baikal:nginx
    container_name: baikal
    restart: unless-stopped
    ports:
      - "8080:80"
    volumes:
      - ./config:/var/www/baikal/config
      - ./Specific:/var/www/baikal/Specific
    deploy:
      resources:
        limits:
          memory: 256M
        reservations:
          memory: 128M
    environment:
      - TZ=Europe/Moscow

Для варианта с MySQL добавляется отдельный контейнер базы:

  db:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: change_me
      MYSQL_DATABASE: baikal
      MYSQL_USER: baikal
      MYSQL_PASSWORD: change_me_too
    volumes:
      - ./mysql-data:/var/lib/mysql
    deploy:
      resources:
        limits:
          memory: 384M

С такой связкой (Baïkal-контейнер + MariaDB) стоит закладывать VPS от 1 ГБ, чтобы под саму ОС и Docker-демон осталось хотя бы 300-400 МБ свободных — Docker сам по себе добавляет 50-100 МБ накладных расходов на контейнеризацию. Если разворачиваете стек впервые, общий порядок настройки Docker Compose под прод (сети, restart-политики, лимиты) разобран в статье про пошаговую установку Docker Compose на Ubuntu 24.04.

Оптимизация PHP-FPM под ограниченную память

Если сервер урезан до 512 МБ-1 ГБ, главный рычаг экономии — настройки пула PHP-FPM в /etc/php/8.3/fpm/pool.d/www.conf:

pm = dynamic
pm.max_children = 4
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
pm.max_requests = 500

pm.max_children — это верхний потолок одновременных PHP-процессов. Для Baïkal с редкими короткими запросами 4 воркеров с запасом хватает даже на 20-30 активных пользователей — они не бьют по серверу одновременно, разве что у вас корпоративный push-sync с общим расписанием. pm.max_requests перезапускает воркер после N запросов — полезно против медленных утечек памяти в самом PHP, почти бесплатно по производительности.

Второй рычаг — отключить неиспользуемые PHP-расширения. Baïkal реально нужны: pdo_sqlite или pdo_mysql, xml, dom, mbstring, curl, zip для экспорта. Всё остальное (gd, imagick, intl, если не используете локализацию панели) можно смело убрать из php.ini — каждое загруженное расширение чуть увеличивает базовый footprint воркера.

Мониторинг и что делать при нехватке памяти

Прежде чем апгрейдить тариф, проверьте реальное потребление:

free -h
docker stats --no-stream   # если через Docker
systemctl status php8.3-fpm

Если видите, что своп активно используется постоянно (не разово при пике, а стабильно), а не только резервируется — это сигнал реального дефицита памяти, а не запас на будущее. Частые признаки нехватки: PHP-FPM воркеры падают в лог с WARNING: [pool www] server reached pm.max_children, ответы /admin/ или /cal.php/ начинают идти с задержкой при нескольких одновременных клиентах, dmesg показывает killed процессы через OOM killer.

Если ресурсов не хватает — сначала попробуйте снизить pm.max_children и добавить своп (это дёшево и быстро), и только если проблема сохраняется при нормальной нагрузке — переходите на VPS с большим объёмом RAM. Для Baïkal это редко требуется: даже реальные развёртывания на 50+ пользователей стабильно держатся в 2 ГБ, если не тащить на том же сервере что-то более тяжёлое. Отдельно не забывайте про регулярные бэкапы базы и конфигов — для контейнерных томов подойдёт связка вроде описанной в статье про BorgBackup в Docker Compose.

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