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

MAATRIX

Если Invoice Ninja кажется избыточным — десятки настроек, модулей и вкладок, половину которых вы никогда не откроете, — Crater работает как более скромная альтернатива: инвойсы, оценки (estimates), клиенты, платежи и базовая отчётность, без перегруза функциями. Собран на Laravel и Vue.js, что снимает часть вопросов по стеку, но не снимает главного: под какой VPS его заводить. Разберём, из чего складывается расход памяти и сколько реально закладывать — от одиночного фрилансера до небольшой команды с регулярными счетами.

Что такое Crater и из чего он сделан

Crater — открытый self-hosted инструмент для выставления счетов и оценок, построенный на классической для Laravel-проектов схеме: PHP-бэкенд на Laravel отдаёт REST API, а интерфейс — это Vue.js SPA, собранная в статические JS/CSS-файлы на этапе установки и раздаваемая тем же веб-сервером. Это важная деталь для памяти: Node.js нужен только на шаге npm run build при установке или обновлении, в рантайме постоянного Node-процесса нет — в отличие от сервисов, где фронтенд крутится на собственном JS-сервере.

Из зависимостей в рантайме: PHP-FPM (или mod_php) под сам Laravel, MySQL или MariaDB как база данных — это официально поддерживаемая и наиболее протестированная связка, PostgreSQL в части инсталляций Laravel-проектов работает, но для Crater конкретно лучше свериться с актуальной документацией перед тем как на неё закладываться. Отправка email (счетов, оценок, напоминаний об оплате) и генерация повторяющихся (recurring) инвойсов идут через стандартный для Laravel механизм: планировщик (artisan schedule:run по cron) плюс очередь заданий, которую можно гонять на database-драйвере (без доп. сервисов, но медленнее) или на Redis (быстрее, но плюс один демон).

По сравнению с Invoice Ninja, которая исторически обросла модулями (несколько шлюзов оплаты «из коробки», кастомные PDF-дизайнеры, отдельные сервисы для рендеринга), Crater держит функциональность уже — и это прямо отражается на количестве процессов, которые нужно держать в памяти постоянно.

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

Реальный расход RAM на сервере с Crater — сумма нескольких компонентов:

• PHP-FPM воркеры под Laravel — каждый активный воркер держит 30-60 МБ (сервис-контейнер, Eloquent ORM, автозагрузка классов фреймворка). Пул из 3-5 воркеров — это 150-300 МБ.
• Веб-сервер — nginx перед PHP-FPM берёт 5-15 МБ базово плюс 1-3 МБ на воркер-процесс; Apache с mod_php обычно тяжелее из-за встроенного интерпретатора в каждом дочернем процессе.
• MySQL/MariaDB — отдельный демон, который в простое держит 150-300 МБ вне зависимости от объёма базы, плюс innodb_buffer_pool_size, который вы явно зададите в конфиге.
• Queue worker (artisan queue:work) — если хотите, чтобы письма и генерация повторяющихся счетов не блокировали интерфейс, этот процесс должен работать постоянно (обычно под supervisor) и держит 30-60 МБ сам по себе.
• Redis (опционально) — как драйвер очереди и кеша, в простое занимает 5-15 МБ, редко становится узким местом при типичных объёмах Crater.
• Генерация PDF — разовый всплеск на момент формирования счёта или оценки в PDF; величина зависит от того, каким движком рендерится документ (см. отдельный раздел ниже), но в среднем это 30-80 МБ на процесс, освобождается сразу после сохранения файла.
• ОС и системные службы — минимальный Ubuntu/Debian без графики забирает 100-200 МБ на ядро, systemd, cron, sshd.

Итог: даже без очереди и Redis, Crater на MySQL — это уже минимум пара сотен мегабайт постоянного расхода на одну только СУБД, поверх которой садится PHP-FPM и веб-сервер.

Сколько RAM закладывать по сценариям

Цифры ниже — практический ориентир, у вас может отличаться в зависимости от версии PHP, числа установленных модулей, объёма клиентской базы и частоты выставления счетов — считайте это отправной точкой, а не гарантией.

Для одного фрилансера с редкими счетами минимально рабочий вариант — 1 ГБ RAM: Debian/Ubuntu minimal (~120-150 МБ), nginx + PHP-FPM с пулом на 3 воркера (~150-250 МБ), MySQL с уменьшенным innodb_buffer_pool_size (~150-200 МБ), и запас на разовый рендер PDF. Очередь в этом сценарии можно не заводить вовсе — письма и PDF формируются синхронно прямо в момент клика «Отправить», это чуть медленнее для пользователя, но экономит постоянный процесс.

На 512 МБ Crater формально может стартовать, но с MySQL, который сам по себе претендует на 150+ МБ в простое, риск упереться в OOM при первой же одновременной операции (composer install, миграция, npm build при обновлении) высок — экономить последние 512 МБ здесь не стоит.

MySQL/MariaDB под Crater на слабом VPS

По умолчанию MySQL/MariaDB настроены с оглядкой на серверы с большим запасом памяти, и на VPS с 1-2 ГБ это стоит подрезать вручную. Ключевой параметр — innodb_buffer_pool_size, который по умолчанию может быть завышен относительно объёма RAM:

# /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
innodb_buffer_pool_size = 128M
innodb_log_file_size = 32M
max_connections = 30
table_open_cache = 200

Для базы Crater это разумный старт на 1-2 ГБ VPS — объём данных (клиенты, счета, позиции) редко большой в мегабайтах, и буферный пул на 128 МБ обычно хватает с запасом даже на несколько тысяч записей. На 4 ГБ и выше можно поднять innodb_buffer_pool_size до 256-512 МБ без риска задушить остальные процессы.

Проверить, сколько реально ест MySQL после старта:

mysqladmin -u root -p status
mysql -u root -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
free -h

Если после установки Crater у вас на счету не хватает памяти под саму СУБД и остальные процессы, есть смысл сперва разобраться, правильно ли настроен своп на сервере — на маленьких VPS это дешёвая страховка от OOM в момент пиковых операций вроде обновления или миграции базы.

PDF-генерация инвойсов: где узкое место

Формирование PDF — самая заметная разовая нагрузка на память в жизненном цикле Crater: клиент нажимает «Скачать» или «Отправить» — сервер должен собрать HTML-шаблон счёта с логотипом, позициями и суммами и превратить его в PDF-файл. Как и большинство Laravel-приложений этого класса, Crater обычно решает эту задачу через PHP-библиотеку для генерации PDF без отдельного браузерного процесса — это существенно легче по памяти, чем решения на headless-браузере (Chromium), которые для точного соответствия CSS-вёрстке запускают полноценный процесс браузера на каждый рендер и могут кратковременно съедать несколько сотен мегабайт. Именно так устроена генерация PDF в некоторых конкурентах, включая часть версий Invoice Ninja — и это одна из причин, почему Crater субъективно легче держать на скромном VPS.

На практике это означает: счёт с парой позиций и логотипом рендерится в PDF за доли секунды и почти не заметен в графике памяти, а вот массовая генерация — например, скрипт, который разом формирует PDF для сотни счетов за отчётный период, — может создать заметный пик, если такие операции идут параллельно, а не последовательно. Если планируете подобный batch-экспорт регулярно, разумно гнать его через очередь заданий, а не синхронным HTTP-запросом с таймаутом.

Docker Compose или ручная установка на LAMP

Crater можно поставить и вручную на LAMP/LEMP-стек (Linux + nginx/Apache + MySQL + PHP), и через Docker Compose — выбор влияет на память не радикально, но 50-100 МБ накладных расходов на Docker-демон и изоляцию контейнеров стоит закладывать сверху.

Пример compose-файла с ограничением памяти под MySQL и Redis:

services:
  app:
    image: crater-invoice/crater
    container_name: crater
    restart: unless-stopped
    ports:
      - "8080:80"
    environment:
      - DB_HOST=mysql
      - DB_DATABASE=crater
      - DB_USERNAME=crater
      - DB_PASSWORD=change_me
    depends_on:
      - mysql
    deploy:
      resources:
        limits:
          memory: 512M

  mysql:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: crater
      MYSQL_USER: crater
      MYSQL_PASSWORD: change_me
      MYSQL_ROOT_PASSWORD: change_me_too
    volumes:
      - ./mysql-data:/var/lib/mysql
    command: --innodb-buffer-pool-size=128M
    deploy:
      resources:
        limits:
          memory: 384M

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 96M

Официальный образ конкретной сборки Crater может отличаться по имени и переменным окружения от примера выше — перед разворотом сверьтесь с актуальным README проекта. Общий принцип с сетями, restart-политиками и лимитами памяти для Docker Compose в проде разобран отдельно, если вы впервые настраиваете такое окружение.

Ручная установка на «голом» VPS (без Docker) экономит те самые 50-100 МБ накладных расходов и даёт больше контроля над php.ini и конфигом MySQL, но требует руками настраивать PHP-FPM пул, nginx vhost и supervisor для очереди — на 1 ГБ VPS этот выигрыш в памяти часто стоит потраченного времени, на 4+ ГБ разница уже не критична и Docker удобнее для обновлений.

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