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

MAATRIX

PostHog — это не одно приложение, а связка из пяти-шести сервисов: событийная база на ClickHouse, реляционная база на PostgreSQL, очереди на Redis, плагин-сервер для обработки событий и веб-приложение поверх всего этого. Поэтому вопрос «сколько RAM нужно для PostHog» распадается на вопрос «сколько нужно каждому компоненту» — и именно ClickHouse, а не сам PostHog, обычно определяет итоговую цифру. Разберём, куда уходит память в self-hosted-инсталляции и как посчитать реальный объём под свою нагрузку.

Из чего состоит self-hosted PostHog и куда уходит память

Официальный self-hosted-дистрибутив PostHog (тот, что разворачивается через docker-compose для «хобби»-инсталляций и небольших команд) поднимает сразу несколько контейнеров, и каждый со своим профилем потребления памяти:

• ClickHouse — колоночная СУБД, в которой физически лежат события: клики, просмотры страниц, кастомные события, данные для воронок и ретеншена. Основной потребитель RAM в системе — сюда идут буферы слияния частей (merge), кеш засечек (mark cache) и память под сами запросы аналитики.
• PostgreSQL — метаданные: пользователи, организации, проекты, определения фича-флагов, настройки дашбордов. Объём данных на порядки меньше, чем в ClickHouse, поэтому и памяти нужно заметно меньше.
• Redis — брокер очередей для Celery-задач (пересчёт когорт, вебхуки, плановые задачи) и кеш для часто запрашиваемых значений, включая флаги фичей на чтение.
• Plugin server (Node.js) — обрабатывает входящий поток событий: валидация, обогащение, запись в ClickHouse, вызов плагинов и дестинаций. При всплесках трафика именно здесь раздувается память под очередь необработанных событий.
• Веб-приложение (Django) и воркеры Celery — UI, API, расчёт графиков и агрегаций по запросу. Каждый воркер — отдельный процесс, и потребление памяти растёт с их числом.
• Object storage (обычно MinIO или совместимый S3) — записи сессий (session replay). Сами записи на диске, но plugin server, который их собирает, тоже держит буферы в памяти.

Разработчики PostHog прямо предупреждают: self-hosted рассчитан на команды, готовые администрировать распределённую систему, и для небольшого потока событий часто проще пользоваться облачной версией. Но если вы уже решили хостить сами — вот реальные ориентиры по памяти.

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

Официальный минимум для «хобби»-деплоя PostHog через docker-compose на момент написания — около 4 vCPU и 16 ГБ RAM на один сервер, где крутятся все компоненты сразу. Это стартовая точка, а не универсальная цифра — конкретный объём событий, retention и включён ли session replay сдвигают требования в обе стороны:

Эти цифры — ориентир для планирования, а не гарантия для вашей схемы событий: сотни кастомных свойств на каждое событие или длинный retention по когортам разгоняют объём данных в ClickHouse (а значит и память под слияния и кеш) быстрее, чем просто число событий в месяц. Если сомневаетесь, с какой конфигурации сервера стартовать под аналитическую нагрузку, полезно заранее заглянуть в разбор ClickHouse или PostgreSQL для аналитики — PostHog как раз использует именно такую комбинацию.

ClickHouse — главный потребитель памяти

Из всех компонентов PostHog именно ClickHouse съедает RAM быстрее остальных — по тем же причинам, что и в любой другой инсталляции ClickHouse: чем больше данных, тем активнее фоновые слияния (merge) частей таблицы, а слияния требуют памяти пропорционально размеру объединяемых кусков. Плюс кеш засечек (mark cache) и кеш несжатых данных, которые ускоряют повторные запросы, но тоже забирают память из общего пула.

Практические моменты для сайзинга ClickHouse под PostHog:

• Retention событий напрямую влияет на объём данных — год сырых событий вместо трёх месяцев пропорционально увеличивает таблицы, а вместе с ними и требования к памяти под слияния и кеш.
• Число уникальных свойств событий увеличивает кардинальность: PostHog хранит их в JSON-подобных колонках, и широкая схема свойств раздувает объём данных на каждое событие сильнее, чем кажется на первый взгляд.
• Параллельные тяжёлые insights (воронки, ретеншен по когортам) съедают память под выполнение запроса — если несколько пользователей одновременно смотрят тяжёлые дашборды, пик потребления заметно превышает «спокойный» уровень.
• max_server_memory_usage ограничивает суммарное потребление процессом и защищает сервер от исчерпания памяти одним неудачным запросом — стоит выставлять явно, а не полагаться на дефолт.

Если разворачиваете ClickHouse для PostHog не через готовый docker-compose, а отдельно (оправдано от нескольких десятков млн событий в месяц), принципы установки и тюнинга — в статье как установить и настроить ClickHouse на VPS, типичные проблемы конфигурации — в разборе частых ошибок ClickHouse на сервере.

PostgreSQL, Redis и очереди: сколько закладывать сверху

На фоне ClickHouse остальные компоненты выглядят скромно, но игнорировать их нельзя — суммарно они добавляют заметную долю от общего объёма RAM:

• PostgreSQL — для метаданных, настроек и определений флагов обычно хватает 1-2 ГБ под процесс плюс системный файловый кеш поверх. Это база не для событий, а для конфигурации приложения, растёт она медленно даже с ростом числа пользователей продукта.
• Redis — брокер Celery и кеш для чтения фича-флагов (SDK на клиентах может дёргать флаги очень часто, и Redis должен отвечать быстро). На среднюю инсталляцию достаточно 1-4 ГБ, но при множестве активных флагов с условиями по когортам закладывайте больше.
• Plugin server — при всплесках трафика, если ClickHouse не успевает принимать поток, события буферизуются в памяти plugin server перед записью. Это частый неожиданный источник роста RAM именно у этого сервиса, а не у ClickHouse.
• Celery-воркеры — каждый воркер отдельный процесс Python (обычно от нескольких сотен МБ до 1 ГБ в зависимости от задач). Число параллельных воркеров напрямую умножается на потребление памяти.

Если Redis используется не только под PostHog, но и под другие сервисы на том же сервере, стоит явно ограничивать maxmemory и следить за политикой вытеснения. Общие принципы настройки — в статье как установить и настроить Redis на VPS, симптомы нехватки памяти у Redis — в разборе высокого потребления памяти Redis. Для PostgreSQL логика shared_buffers и work_mem под конкретный объём RAM — в статье установка и настройка PostgreSQL на VPS.

docker-compose: лимиты памяти по сервисам

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

# docker-compose.override.yml — лимиты для сервера с 32 ГБ RAM
services:
  clickhouse:
    deploy:
      resources:
        limits: { memory: 16g }
  postgres:
    deploy:
      resources:
        limits: { memory: 3g }
  redis:
    deploy:
      resources:
        limits: { memory: 2g }
  plugin-server:
    deploy:
      resources:
        limits: { memory: 4g }
  worker:
    deploy:
      resources:
        limits: { memory: 3g }

Суммарно лимиты в примере дают около 28 ГБ из 32 ГБ физической памяти — оставшиеся ~4 ГБ идут под файловый кеш ОС, служебные процессы Docker и запас на пики. Лимиты строго ниже физической памяти, а не впритык к ней, — защита от ситуации, когда ядро убивает процессы через OOM killer в непредсказуемом порядке вместо того, чтобы Docker аккуратно ограничил конкретный контейнер.

Если вы ещё не выстроили общий подход к продакшен-конфигурации docker-compose (health checks, restart-политики, лимиты по всем сервисам разом), стоит сначала посмотреть разбор в статье docker-compose для продакшена на VPS — там же типичные ошибки конфигурации, актуальные и для стека PostHog.

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

PostHog сигнализирует о нехватке RAM по-разному в зависимости от того, какой компонент упирается в лимит:

# ядро убивало процессы по нехватке памяти?
dmesg -T | grep -i "killed process"

# память по контейнерам в реальном времени
docker stats --no-stream

# активные тяжёлые запросы ClickHouse прямо сейчас
docker exec -it <clickhouse-container> clickhouse-client \
  --query "SELECT query, memory_usage, elapsed FROM system.processes ORDER BY memory_usage DESC"

# память Redis и политика вытеснения
docker exec -it <redis-container> redis-cli INFO memory

Типичные симптомы и что они означают:

• ClickHouse периодически перезапускается, в логах Memory limit exceeded. max_server_memory_usage выставлен ниже реальных потребностей тяжёлых запросов или слияний — либо увеличивайте лимит при наличии запаса RAM, либо снижайте нагрузку: упрощайте insights, сокращайте retention, добавляйте TTL на старые партиции.
• UI подтормаживает на сложных воронках и ретеншене, но контейнеры не падают. Обычно нехватка памяти под промежуточные структуры агрегации — помогает RAM под ClickHouse либо упрощение insights.
• Plugin server стабильно растёт в памяти при всплесках трафика и не откатывается после. Похоже на накопление необработанной очереди событий — проверьте, не отстаёт ли запись в ClickHouse от входящего потока.
• Redis: used_memory близко к maxmemory, много evicted keys. На кеше флагов это риск задержек при чтении на клиентах; поднимайте maxmemory или разносите Redis для кеша и для очередей по разным инстансам.

Долгосрочно полезнее не ждать инцидента, а вынести метрики памяти по каждому сервису на общий дашборд — принципы те же, что и для любой связки баз данных, разобраны в статье мониторинг баз данных через Grafana, а за диском (события в ClickHouse и записи session replay быстро его заполняют) стоит следить отдельно — см. мониторинг диска на VPS.

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