Сколько RAM нужно для Sentry (self-hosted)

MAATRIX

Официальная рекомендация для self-hosted Sentry — «от 8 ГБ RAM» — звучит скромно, пока не откроешь docker compose ps и не увидишь два десятка контейнеров, часть из которых уже несколько раз перезапустилась по OOM. Проблема в том, что Sentry — это не сервис, а связка из Kafka, ClickHouse, Postgres, Redis и полудюжины воркеров, и каждый из них хочет памяти по-своему. Разберём, кто из этой связки ест RAM на самом деле, сколько закладывать под разный объём событий и как не гадать, а увидеть нехватку памяти заранее.

Почему Sentry self-hosted — это не один процесс, а десяток

Когда вы делаете docker compose up -d в каталоге getsentry/self-hosted, поднимается не «Sentry», а целая инфраструктура вокруг него:

• Postgres — хранит метаданные: проекты, пользователей, релизы, настройки. Сами события здесь не лежат.
• ClickHouse — колоночная СУБД, куда пишутся сами события и трассировки. Основной потребитель диска и один из основных потребителей RAM под нагрузкой.
• Kafka + Zookeeper — очередь, через которую события идут от приёмника до обработки и записи в ClickHouse. Классическая JVM-нагрузка со своим heap.
• Redis — кеш, очереди задач для Celery-воркеров, rate-limiting.
• Snuba — прослойка, которая транслирует запросы Sentry в запросы к ClickHouse; несколько процессов (api, consumer, replacer и другие).
• Relay — приёмник событий на границе, первичная валидация и семплирование до того, как событие попадёт в очередь.
• Symbolicator — символизация стектрейсов (native, minidump) — не всегда активно нагружен, но держит память под кеш символов.
• web, worker, cron — сам Python/Django-стек Sentry: веб-интерфейс, фоновые задачи, периодические джобы.

Каждый из этих сервисов — отдельный контейнер с собственным потреблением памяти, и они не делят её «по справедливости»: ClickHouse и Kafka заберут столько, сколько разрешит операционная система, если явно не ограничить лимиты. Отсюда и разброс в рекомендациях: «Sentry на 4 ГБ работает» технически верно для пустого стенда без единого события и ложно для чего угодно ближе к продакшену.

Минимум, комфорт и когда закладывать больше

Если ставите self-hosted Sentry на VPS и не хотите разбираться в heap-настройках каждого компонента вручную, ориентируйтесь на объём входящих событий — это единственный параметр, который реально двигает потребление RAM вверх:

Цифры в таблице — ориентир для планирования, а не гарантированный порог: у кого-то 16 ГБ держат десяток проектов без единого рестарта, у кого-то один шумный проект с частыми исключениями и большими стектрейсами упирается в 16 ГБ быстрее ожидаемого. Если сомневаетесь, с какого объёма стартовать сервер — берите нижнюю границу «комфортного» диапазона: апгрейд RAM на VPS обычно решается сменой тарифа за минуты, без переустановки стека.

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

Точных фиксированных цифр тут не существует — потребление зависит от версии Sentry, потока событий и того, сколько партиций и реплик вы задали Kafka. Но порядок величины и то, кто за что отвечает, стабильны от инсталляции к инсталляции:

• Kafka — JVM-процесс с фиксированным heap (KAFKA_HEAP_OPTS, по умолчанию около 1 ГБ в стандартном compose-файле self-hosted). Сверх heap Kafka активно использует файловый кеш ОС для сегментов очереди — так же, как Elasticsearch использует его для Lucene. На тихом стенде это скромный потребитель, под нагрузкой с несколькими топиками и партициями — один из заметных.
• Zookeeper — небольшой JVM-процесс, обычно держится в пределах few сотен мегабайт-1 ГБ heap, не растёт с потоком событий так же резко, как Kafka.
• ClickHouse — не имеет фиксированного heap как JVM, но активно использует память под кеш блоков и промежуточные структуры при мёрже партов на диске. На инсталляциях с большим retention и активной записью ClickHouse способен стать главным потребителем RAM в стеке — особенно в моменты фоновых мёрджей parts, когда нагрузка на память подскакивает без видимого роста трафика событий.
• Postgres — сравнительно скромный потребитель для Sentry-нагрузки: метаданные, а не сами события, растут медленно. Дефолтных shared_buffers обычно достаточно, если только у вас не сотни активных проектов с частыми изменениями конфигурации.
• Redis — держит очереди Celery-задач и кеш; при нормальной обработке очередей память стабильна, но если воркеры отстают от потока задач (например, после простоя или сбоя), очередь в Redis может разрастись и потянуть память вверх — это первый признак, что воркеров не хватает, а не что Redis «сломан».
• Snuba, Relay, Symbolicator, web/worker/cron — набор Python-процессов; каждый по отдельности легче JVM-сервисов, но их много, и при высокой конкурентности (несколько worker-процессов Celery, несколько инстансов web) суммарное потребление складывается заметно.

Практический вывод: если ищете, куда «утекает» память на вашем сервере, не начинайте с Postgres — почти всегда основная динамика идёт от Kafka и ClickHouse, а Redis раздувается вторично, если за ними не успевают воркеры.

Как выставить лимиты и не дать одному сервису забрать всё

По умолчанию контейнеры Docker Compose не ограничены по памяти — если не задать лимиты явно, прожорливый сервис может вытеснить соседей и довести хост до OOM killer ядра, который убьёт процесс не глядя на то, насколько он критичен. Ограничения задаются в compose-файле:

services:
  clickhouse:
    deploy:
      resources:
        limits:
          memory: 6g
        reservations:
          memory: 2g

  kafka:
    environment:
      - KAFKA_HEAP_OPTS=-Xmx1g -Xms1g
    deploy:
      resources:
        limits:
          memory: 2g

Для JVM-сервисов (Kafka, Zookeeper) лимит контейнера должен быть заметно выше, чем -Xmx, — сама JVM использует память сверх heap (метапространство, потоковые стеки, native-буферы), и если зажать контейнер вплотную к heap, он всё равно упрётся в лимит и будет убит ядром вместо самой JVM, которая иначе просто выдала бы OutOfMemoryError в лог. Для ClickHouse удобнее ограничивать не только через Docker, но и параметром max_memory_usage в конфиге сервера — так ClickHouse сам откажет тяжёлому запросу с понятной ошибкой вместо того, чтобы довести контейнер до убийства ядром.

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

Retention событий — главный рычаг, который двигает потребление RAM со временем

RAM под Sentry редко «утекает» из-за утечки памяти в коде — гораздо чаще дело в том, что объём данных в ClickHouse растёт быстрее, чем вы рассчитывали при первой прикидке сервера. Ключевая настройка — SENTRY_EVENT_RETENTION_DAYS в .env: по умолчанию события хранятся 90 дней, и чем дольше retention и чем выше поток событий, тем больше данных ClickHouse держит активными, тем чаще идут фоновые мёрджи partов и тем выше базовое потребление памяти под них.

Практический подход, который экономит нервы на маленьком сервере:

• Начните с retention 14-30 дней, если основная цель — ловить и чинить свежие ошибки, а не вести долгий архив инцидентов.
• Снижайте tracesSampleRate в SDK приложения (пример из статьи про установку Sentry self-hosted) — трассировка производительности плодит события в разы активнее, чем обычные исключения, и именно она чаще всего неожиданно раздувает ClickHouse на маленьком сервере.
• Если проектов много, но события шумные (повторяющиеся однотипные ошибки), настройте fingerprint-группировку и rate-limiting на уровне проекта в Sentry — это снижает поток в Kafka и ClickHouse без потери диагностической ценности.

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

Как заметить нехватку памяти до того, как контейнеры начнут падать

Три источника сигналов, по которым нехватка RAM видна раньше, чем до продакшена долетит жалоба пользователя:

# Живое потребление по каждому контейнеру
docker stats --no-stream

# Был ли OOM killer на уровне ядра — и какой процесс он убил
dmesg -T | grep -i "killed process"

# Статус контейнеров: кто в restarting/unhealthy
docker compose ps

# Логи конкретного упавшего сервиса
docker compose logs --tail=200 clickhouse
docker compose logs --tail=200 kafka

Если docker compose ps регулярно показывает snuba-*, kafka или clickhouse в состоянии Restarting, а dmesg подтверждает Killed process рядом по времени — это не разовая случайность, а системная нехватка RAM под текущий трафик, и решается либо добавлением памяти, либо ужатием retention/потока событий из предыдущего раздела.

Для постоянного наблюдения разумнее не бегать вручную по docker stats, а вынести потребление памяти каждого контейнера на дашборд рядом с общими метриками сервера — принципы те же, что и для любых баз данных на сервере: подробнее в статье про мониторинг баз данных через Grafana, а сам стек мониторинга разобран в установке Grafana и Prometheus. Держать своп на сервере с Sentry стоит как аварийную подушку, а не рабочий механизм — JVM-сервисы (Kafka, Zookeeper) особенно плохо переносят выгрузку heap в swap, логика подбора размера свопа разобрана в статье про правильный размер swap для VPS.

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