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

MAATRIX

Cachet — это публичная статус-страница вашего сервиса: компоненты, инциденты, uptime-история, подписка на уведомления. Задача выглядит скромной, но выбирать тариф на глаз не хочется — ошибётесь в меньшую сторону, и страница со статусом ляжет именно в тот момент, когда у вас реально что-то упало, а это худшее время для простоя. Разберём, из чего складывается расход памяти у связки PHP-FPM + MySQL + очереди уведомлений, которая и есть Cachet, и сколько RAM закладывать под разные сценарии — от личного проекта до статус-страницы компании с сотнями подписчиков.

Что внутри Cachet и почему это важно для памяти

Cachet написан на PHP (фреймворк Laravel) и требует реляционную БД — MySQL, MariaDB или PostgreSQL, есть и вариант с SQLite для совсем небольших инсталляций. Это классическое серверное веб-приложение: страница статуса рендерится на бэкенде при каждом запросе, а не отдаётся статикой. Память расходуют четыре компонента:

• Веб-сервер (nginx или Apache) — принимает запросы, отдаёт статику, проксирует в PHP-FPM. Лёгкий, 10–20 МБ базового оверхеда.
• PHP-FPM — пул воркеров Laravel-приложения. Один воркер обслуживает один запрос: открытие публичной страницы статуса, вход в админку, обновление статуса компонента.
• БД — хранит компоненты, инциденты, историю обновлений и подписчиков. У MySQL/MariaDB свой аппетит через innodb_buffer_pool_size, у PostgreSQL — через shared_buffers.
• Очередь и опционально Redis — Cachet использует систему очередей Laravel для отправки email-уведомлений подписчикам при смене статуса компонента или создании инцидента. По умолчанию можно работать на синхронной очереди или через таблицу в БД, но под нагрузкой разумнее вынести очередь и кэш в Redis.

Важная особенность именно для расчёта памяти: публичная статус-страница обычно получает трафик очень неравномерно — тихо в обычное время и резкий всплеск запросов ровно тогда, когда что-то сломалось и все разом обновляют страницу проверить, у всех ли лежит. Именно этот пик, а не средняя нагрузка, должен определять запас по RAM.

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

Ниже не измеренные бенчмарки, а инженерный ориентир из архитектуры (число воркеров PHP-FPM × средний вес процесса + буфер БД + ОС). Точные цифры у вас сдвинутся в зависимости от версии PHP, включённого OPcache и того, используете ли вы Redis отдельным процессом.

Если сомневаетесь между соседними уровнями — берите больший: статус-страница по определению должна пережить худший день вашей инфраструктуры, а не только обычный вторник. Общий подход к запасу по памяти на любом сервисе разобран в статье сколько оперативной памяти закладывать с запасом.

Docker vs классическая установка: разница в памяти

Cachet можно поднять двумя путями, и они по-разному ведут себя с точки зрения RAM.

Docker Compose — быстрый старт с образом приложения и отдельным контейнером БД:

version: "3"
services:
  cachet:
    image: cachethq/docker:latest
    environment:
      - DB_DRIVER=mysql
      - DB_HOST=cachet_db
      - DB_DATABASE=cachet
      - DB_USERNAME=cachet
      - DB_PASSWORD=changeme
      - CACHE_DRIVER=redis
      - QUEUE_DRIVER=redis
      - REDIS_HOST=cachet_redis
      - APP_KEY=base64:сгенерируйте_свой_ключ
    ports:
      - 8000:8000
    depends_on:
      - cachet_db
      - cachet_redis
    restart: unless-stopped

  cachet_db:
    image: mariadb:10.11
    environment:
      - MYSQL_ROOT_PASSWORD=changemeroot
      - MYSQL_DATABASE=cachet
      - MYSQL_USER=cachet
      - MYSQL_PASSWORD=changeme
    volumes:
      - ./db:/var/lib/mysql
    restart: unless-stopped

  cachet_redis:
    image: redis:7-alpine
    restart: unless-stopped

Три контейнера — три независимых процесса, каждый со своим базовым оверхедом плюс накладные расходы самого Docker. На сервере 1 ГБ это ощутимо: контейнеры съедают заметный кусок памяти ещё до первого открытия статус-страницы. Настройку продакшен-стека под Docker Compose в целом разбирали отдельно — Docker Compose для продакшена: пошаговая установка.

Классическая установка на LEMP экономичнее на слабых машинах — нет накладных расходов контейнеризации, легче тонко настроить pm.max_children под конкретный объём RAM:

apt install -y nginx mariadb-server php8.2-fpm php8.2-mysql \
  php8.2-mbstring php8.2-xml php8.2-curl php8.2-zip php8.2-gd \
  php8.2-bcmath php8.2-intl composer git

git clone https://github.com/cachethq/cachet.git /var/www/cachet
cd /var/www/cachet
composer install --no-dev --optimize-autoloader
cp .env.example .env
php artisan key:generate
php artisan migrate --force

Если вы разворачиваете сервер с нуля, общая последовательность настройки Ubuntu под продакшен-стек с nginx и БД описана в статье Docker Compose для продакшена на Ubuntu 24.04: пошаговая установка — принципы применимы и к классической установке без контейнеров.

Настройка PHP-FPM под доступную память

Главный рычаг на стороне Cachet — число процессов PHP-FPM. Каждый воркер держит интерпретатор PHP плюс загруженный код Laravel — ориентировочно 40–70 МБ на процесс с включённым OPcache (без него заметно больше, включайте его всегда).

Пример pool.d/cachet.conf под сервер 2 ГБ, где под PHP разумно выделить около 600–700 МБ (остальное — MySQL, Redis, nginx, ОС):

[cachet]
user = www-data
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 500

Формула грубая, но рабочая: pm.max_children = доступная_под_php_память_МБ / средний_вес_процесса_МБ. Специфика статус-страницы в том, что число одновременных запросов почти всегда невелико в обычное время, но резко подскакивает именно тогда, когда происходит инцидент и трафик на публичную страницу растёт кратно — на этот пик и нужен запас, а не на среднюю нагрузку рабочего дня.

В php.ini для FPM-пула Cachet хватает memory_limit в 256M — раздувать его смысла нет, приложение не обрабатывает тяжёлые файлы, только текстовые обновления статусов и инцидентов.

База данных: MySQL/MariaDB и SQLite для небольших инсталляций

Для продакшена Cachet официально поддерживает MySQL, MariaDB и PostgreSQL. Ключевой параметр для MySQL/MariaDB — innodb_buffer_pool_size:

# /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
innodb_buffer_pool_size = 128M
innodb_buffer_pool_instances = 1
innodb_log_file_size = 32M
tmp_table_size = 32M
max_heap_table_size = 32M

128 МБ буфера с большим запасом хватает под данные Cachet: таблицы компонентов, инцидентов и подписчиков компактные даже при истории на несколько лет — это не файловое хранилище и не логи, объём растёт медленно. На серверах от 4 ГБ буфер можно поднять до 256–512 МБ, если БД не единственный тяжёлый сервис на машине. Общие принципы такой настройки под ограниченную память разобраны в статье оптимизация MySQL под 1 ГБ RAM — методика применима и к MariaDB под Cachet.

Для личного проекта или теста SQLite снимает необходимость в отдельном процессе БД вообще — файл базы лежит рядом с приложением, память экономится за счёт отсутствия отдельного серверного процесса MySQL. Для продакшена с несколькими одновременными редакторами инцидентов SQLite не рекомендуется — блокировки на запись при конкурентном доступе становятся заметны быстрее, чем на полноценной клиент-серверной БД.

Очереди, Redis и отправка уведомлений подписчикам

Отдельная особенность Cachet, которую часто упускают при расчёте памяти: уведомления подписчикам о новом инциденте или смене статуса компонента отправляются через систему очередей Laravel, а не синхронно в момент клика администратора. Если очередь настроена неверно, письма просто зависают, а не отправляются с задержкой.

Варианты организации очереди по возрастанию требований к памяти:

• Синхронная очередь (QUEUE_DRIVER=sync) — письмо отправляется сразу в момент запроса, отдельного воркера не нужно. Подходит для личного проекта с несколькими подписчиками, но замедляет ответ администратору при рассылке большому числу адресов.
• Очередь через БД (QUEUE_DRIVER=database) — задания хранятся в таблице MySQL, обрабатываются отдельным процессом php artisan queue:work. Дополнительной памяти по сравнению с MySQL, который уже развёрнут, почти не требует — только сам процесс воркера, порядка 30–50 МБ.
• Redis-очередь (QUEUE_DRIVER=redis) — быстрее и надёжнее под нагрузкой, но добавляет отдельный процесс Redis. По умолчанию Redis резервирует память под свой аллокатор заранее, поэтому стоит явно ограничить её через maxmemory, иначе на тесном сервере он может забрать больше, чем нужно приложению такого масштаба:

# redis.conf
maxmemory 128mb
maxmemory-policy allkeys-lru

Установку и базовую настройку Redis на VPS разбирали отдельно в статье как установить и настроить Redis на VPS — она применима и к роли очереди для Cachet, а не только к кэшу.

На сервере с сотнями подписчиков и активными инцидентами (несколько обновлений статуса в день, каждое рассылается всем подписавшимся) Redis-очередь с отдельным queue:work-воркером в связке с supervisor или systemd — разумный минимум, чтобы рассылка не блокировала основной пул PHP-FPM.

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