Сколько RAM нужно для Plausible Analytics

MAATRIX

Plausible привлекает обещанием «лёгкая аналитика без cookie-баннера и без слежки за пользователями», и на сайте проекта официальный минимум звучит скромно. Но стоит поднять self-hosted версию по их же docker-compose файлу — и на VPS с 1-2 ГБ памяти контейнер plausible_events_db рано или поздно падает по OOM, особенно как только на сайт заходит реальный трафик. Дело в том, что «Plausible» — это не один процесс, а связка из трёх сервисов, и один из них — колоночная база данных, которая ведёт себя совсем не так, как привычный MySQL под WordPress. Разберём архитектуру и посчитаем, сколько памяти закладывать под тест и под рабочий продакшен.

Из чего состоит Plausible и почему память считается иначе

Официальный self-hosting репозиторий (plausible/hosting) поднимает docker-compose стек из трёх основных контейнеров:

• plausible — сама веб-панель и API, написаны на Elixir/Phoenix. В покое лёгкий: держит BEAM VM с небольшим числом процессов, память растёт вместе с числом одновременных пользователей дашборда, а не с трафиком отслеживаемых сайтов.
• plausible_db — PostgreSQL, хранит метаданные: список сайтов, пользователей, настройки целей и UTM-разметки. Данные некрупные, память под него предсказуема и почти не зависит от объёма трафика.
• plausible_events_db — ClickHouse, хранит сами события (просмотры страниц, кастомные события). Это ядро системы и главный потребитель ресурсов.

Ключевая разница с типичным self-hosted сервисом: у WordPress или Nextcloud память в основном определяется числом одновременных запросов и кэшем приложения. У Plausible всё иначе — ClickHouse оптимизирован под аналитические запросы по колонкам и агрессивно использует память для двух вещей: буферизации входящих вставок (события пишутся пачками, не по одной строке) и фоновых merge-операций, которые склеивают мелкие куски данных на диске в более крупные. Даже если дашборд никто не открывает, фоновые процессы ClickHouse продолжают работать и потреблять память, пока идёт запись событий.

Поэтому «сколько RAM нужно для Plausible» — это почти всегда вопрос «сколько RAM нужно ClickHouse при вашем объёме событий», плюс небольшой фиксированный оверхед на Postgres, приложение и сам Docker.

Минимум для теста и личных проектов

Если вы поднимаете Plausible для себя — пара личных сайтов, блог, лендинг с трафиком в пределах нескольких тысяч визитов в месяц, — стек в принципе стартует и на 2 ГБ RAM. Но это работа впритык: официальные примеры docker-compose файла не выставляют лимиты памяти по умолчанию, и ClickHouse при инициализации может занять больше, чем кажется логичным для «пустой» базы.

По наблюдениям тех, кто самостоятельно хостит Plausible, ориентировочное распределение памяти в простое (без активной записи событий) выглядит так — это именно ориентир, у вас цифры могут отличаться в зависимости от версий образов и настроек:

Для теста реалистичный минимум — 2 ГБ RAM, 1-2 vCPU, но с пониманием, что запаса на всплеск трафика или на второй тяжёлый сервис на той же машине нет. Для спокойной работы даже личного проекта разумнее закладывать 4 ГБ — разница в цене VPS небольшая, а нервов экономит много: не придётся разбираться, почему ночью упал контейнер с ClickHouse.

Продакшен: несколько сайтов и реальный трафик

Как только счёт идёт на десятки тысяч и выше просмотров страниц в месяц по нескольким сайтам, картина меняется — и меняется она не столько от «трафика» в привычном смысле, сколько от объёма и разнообразия событий, которые ClickHouse должен буферизовать и индексировать.

Практический ориентир для рабочего инстанса:

• 4-8 сайтов, до ~200-300 тысяч просмотров в месяц суммарно — 4 ГБ RAM, 2 vCPU обычно достаточно, но SSD с приличным IOPS важнее лишнего ядра CPU.
• Десятки сайтов, сотни тысяч — единицы миллионов событий в месяц — 8 ГБ RAM, 2-4 vCPU, отдельный диск под volume ClickHouse становится ощутимо полезен.
• Крупная установка на агентство или несколько проектов с высокой кардинальностью событий (много кастомных event props, отслеживание UTM-меток по десяткам источников) — здесь память нужно считать индивидуально: кардинальность (число уникальных комбинаций значений) влияет на размер индексов ClickHouse сильнее, чем просто количество строк.

Важный нюанс: сырое число pageview не так критично, как срок хранения и разнообразие данных. Сайт с 50 тысячами просмотров в месяц, но с активным использованием кастомных событий и свойств (custom event properties), может нагружать ClickHouse сильнее, чем сайт со 200 тысячами простых просмотров без кастомной разметки — потому что каждое уникальное сочетание свойств увеличивает объём индексируемых данных.

Для честного выбора конфигурации разумно на старте держаться консервативной оценки, запустить стек, последить неделю-две за docker stats, и по факту решить — хватает памяти с запасом или пора расширяться. Мигрировать между тарифами VPS обычно быстрее, чем перестраивать архитектуру постфактум.

Почему ClickHouse — главный потребитель и как это увидеть

ClickHouse по умолчанию не сильно ограничивает себя в памяти — рассчитан на выделенные серверы, где ему отдают почти всю доступную RAM. В контейнере на общей VPS с другими сервисами это создаёт риск: без явных лимитов ClickHouse может «съесть» всё, что видит, и спровоцировать OOM-killer у соседних процессов.

Проверить текущее потребление по контейнерам:

docker stats plausible_events_db plausible_db plausible

Внутри самого ClickHouse полезно смотреть на системные таблицы — они показывают, куда реально уходит память:

docker exec -it plausible_events_db clickhouse-client --query \
  "SELECT metric, formatReadableSize(value) FROM system.metrics WHERE metric LIKE '%Memory%'"

Основные регуляторы памяти в конфигурации ClickHouse — это max_server_memory_usage и max_server_memory_usage_to_ram_ratio в config.xml, а также max_memory_usage для отдельных запросов. Официальный образ Plausible обычно поставляется с разумными настройками «из коробки», но если вы сажаете стек на VPS с малым объёмом RAM, стоит явно прописать лимит через переменную окружения или volume с кастомным config.xml, чтобы ClickHouse не пытался вести себя так, будто в его распоряжении вся память сервера. Подробнее про выбор между ClickHouse и более простыми вариантами аналитической базы — в статье ClickHouse или PostgreSQL для аналитики: что выбрать для сервера, а базовая установка ClickHouse отдельно от Plausible разобрана в материале как установить и настроить ClickHouse на VPS.

docker-compose: лимиты памяти под разные объёмы

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

Пример добавления лимитов через mem_limit в docker-compose.yml (формат Compose v2, подходит для сервера на 8 ГБ RAM с небольшим запасом под ОС):

services:
  plausible:
    mem_limit: 768m
    mem_reservation: 256m

  plausible_db:
    mem_limit: 1g
    mem_reservation: 256m

  plausible_events_db:
    mem_limit: 4g
    mem_reservation: 1g

Логика распределения: приложению и Postgres достаточно фиксированного, относительно небольшого лимита, а ClickHouse получает основную долю памяти сервера, потому что именно он масштабируется вместе с ростом трафика. На сервере с 4 ГБ RAM пропорции стоит сдвинуть аккуратнее — например, plausible: 384m, plausible_db: 512m, plausible_events_db: 2g, оставив системе и Docker около 1 ГБ. Если тарифный план и число сайтов позволяют, проще сразу закладывать RAM с запасом, чем потом вручную подгонять лимиты под нехватку — общий подход к этому описан в статье сколько оперативной памяти закладывать с запасом.

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

Своп не заменяет нехватку RAM для ClickHouse — уход в swap резко замедляет merge-операции и запросы к дашборду, потому что колоночная база активно работает с памятью как с быстрым буфером, и подкачка с диска здесь ощущается заметно сильнее, чем для условного PHP-процесса. Тем не менее небольшой своп как страховочная сетка на случай кратковременного всплеска (импорт исторических данных из Google Analytics, резкий скачок трафика) — разумная мера, а не признак недостаточно посчитанной конфигурации. Как правильно рассчитать размер и не полагаться на своп как на основной ресурс, разобрано в статье правильный размер swap для VPS.

Что смотреть при первых признаках нехватки памяти:

# Убитые OOM-killer процессы в системном логе
dmesg -T | grep -i "out of memory"

# Логи самого ClickHouse
docker logs plausible_events_db --tail 100

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

Если контейнер plausible_events_db регулярно перезапускается сам по себе (это видно в docker ps по столбцу STATUS — короткий аптайм после рестарта) и в dmesg есть записи OOM применительно к его PID, значит, лимита памяти либо нет, либо он занижен относительно реального объёма событий. В этом случае либо увеличивают лимит и общий объём RAM на сервере, либо сокращают срок хранения сырых событий в настройках Plausible (retention период для events data), уменьшая рабочий набор данных, который ClickHouse держит «горячим».

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