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

MAATRIX

Disqus не устраивает по трём причинам сразу: реклама в виджете, слежка за читателями и сторонние скрипты, которые тормозят страницу. Commento — self-hosted альтернатива без всего этого: чистый Go-бинарник плюс PostgreSQL, markdown в комментариях, голосования, модерация. Вопрос только один — сколько сервера под это реально нужно, и не окажется ли, что вы держите VPS ради базы данных размером с пустой блог.

Из чего состоит Commento и почему это не WordPress-плагин

Commento — не CMS-модуль и не PHP-скрипт, который подключается к уже существующей базе сайта. Это отдельный сервис: одиночный Go-бинарник (или Docker-образ), который поднимает HTTP API и раздаёт JS-виджет, встраиваемый на страницу тегом <script>, — примерно как у Disqus, только без рекламной сети внутри. Сам виджет отдаёт данные через API, а комментарии, пользователи и голоса хранятся в PostgreSQL.

Это меняет логику расчёта памяти по сравнению с плагином для WordPress или Ghost. Там комментарии живут в той же базе, что и весь остальной контент сайта, и добавочная нагрузка размывается на фоне CMS. У Commento — ровно наоборот: это отдельный процесс и отдельная база, которые вы добавляете к уже работающему сайту (статическому на Hugo или Jekyll, либо динамическому — не важно). Соответственно, считать нужно не «весь сайт», а именно эту добавку: Go-процесс сам по себе лёгкий, а вот PostgreSQL — по умолчанию не самый экономный сосед на маленьком VPS.

Важный нюанс, который стоит проговорить честно: оригинальный проект commento.io в какой-то момент сместил фокус на платное облако, и открытый self-host вариант какое-то время не получал активных обновлений. В экосистеме появились независимые форки (например, известный под именем Commento++), которые продолжают поддержку. Если вы разворачиваете Commento сегодня — сверьтесь, какой форк актуален и поддерживается на момент установки, и берите docker-образ именно оттуда. Архитектура «Go + PostgreSQL» и логика расчёта памяти ниже одинаковы для всех веток проекта.

Сколько RAM нужно: по нагрузке, а не по инсталляции

Сам Go-бинарник Commento в простое ест немного — это типично для компилируемых Go-сервисов без тяжёлых зависимостей: несколько десятков мегабайт резидентной памяти, рост под нагрузкой умеренный, потому что Go не тянет за собой интерпретатор и рантайм-оверхед вроде PHP или Ruby. Проблема не в бинарнике, а в его соседе по серверу.

Дальше — ориентировочная раскладка по сценариям. Это именно ориентир: у вас будет отличаться в зависимости от количества сайтов, подключённых к одному инстансу, глубины истории комментариев и настроек PostgreSQL.

На VPS меньше 1 GB Commento формально запустится, но без свопа рискует упасть по OOM в момент первого же скачка трафика — резервный на Reddit или HN пост с сотней одновременных читателей, каждый из которых грузит виджет с комментариями, легко создаёт всплеск соединений к PostgreSQL. Своп не решает проблему производительности, но спасает от падения сервиса, пока вы не увеличите RAM.

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

Если у вас уже забронирован сервер только под комментарии и он «ест больше, чем ожидалось» — почти наверняка виноват не Go-процесс, а PostgreSQL с настройками по умолчанию. У свежепоставленного Postgres shared_buffers часто выставлен консервативно (около 128 MB), но резидентная память самого процесса плюс служебные (postgres: checkpointer, postgres: walwriter, автовакуум) на маленьком VPS всё равно ощутимо давят на общий бюджет памяти сервера.

Базовый тюнинг под маленькую нагрузку в postgresql.conf:

# для VPS с 1-2 GB RAM, где Postgres обслуживает только Commento
shared_buffers = 256MB
effective_cache_size = 768MB
work_mem = 4MB
maintenance_work_mem = 64MB
max_connections = 50

Держите max_connections небольшим — Commento не открывает сотни параллельных соединений сам по себе, а раздутый лимит соединений — частая причина, почему Postgres резервирует память, которая потом простаивает. Если тюните впервые, не гадайте на глаз — общие принципы подбора shared_buffers, work_mem и effective_cache_size под конкретный объём RAM разобраны в статье про тюнинг PostgreSQL на VPS, она применима к любому сервису на Postgres, не только к Commento.

Отдельно проверьте автовакуум: таблица комментариев с активным голосованием (апвоуты/даунвоуты) получает много UPDATE, и без нормальной работы автовакуума база разбухает мёртвыми строками быстрее, чем растёт реальный объём данных.

Docker Compose или нативная установка — разница в памяти

Оба Commento-бинарник, и PostgreSQL спокойно ставятся нативно на сервер, но на практике большинство разворачивает связку через docker-compose.yml — так проще обновлять оба компонента независимо. Разница в памяти между подходами не в самом Docker (оверхед контейнеризации на Linux мал, это не виртуальная машина), а в том, что́ по умолчанию запускается вместе с образами.

Пример рабочего docker-compose.yml для маленького VPS — сверьте переменные окружения с README актуального форка перед запуском, названия у разных веток проекта могут отличаться:

version: "3.8"

services:
  commento-db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: commento
      POSTGRES_USER: commento
      POSTGRES_PASSWORD: change-me
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    command: >
      postgres -c shared_buffers=256MB
               -c effective_cache_size=768MB
               -c max_connections=50
    deploy:
      resources:
        limits:
          memory: 512M

  commento:
    image: registry.example.org/commento:latest
    restart: unless-stopped
    depends_on:
      - commento-db
    environment:
      COMMENTO_ORIGIN: "https://comments.example.com"
      COMMENTO_PORT: "8080"
      COMMENTO_POSTGRES: "postgres://commento:change-me@commento-db:5432/commento?sslmode=disable"
    ports:
      - "8080:8080"
    deploy:
      resources:
        limits:
          memory: 256M

Лимиты deploy.resources.limits в Docker Compose без Swarm-режима не всегда применяются автоматически — на голом docker compose up их нужно либо запускать через docker compose --compatibility, либо задавать через mem_limit в v2-синтаксисе. Не полагайтесь на цифры в файле как на гарантию — проверьте docker stats после запуска и убедитесь, что реальное потребление укладывается в план VPS.

Пошаговая установка на минимальном сервере

Порядок действий на чистом Ubuntu 24.04 с 1-2 GB RAM:

1. Обновите систему и поставьте Docker с docker-compose-плагином.
2. Настройте своп на 1-2 GB, даже если RAM кажется достаточной — это дешёвая страховка от OOM в момент пиковой нагрузки на PostgreSQL.
3. Разместите docker-compose.yml из примера выше, замените пароль и COMMENTO_ORIGIN на реальный домен виджета.
4. Поднимите обратный прокси с автоматическим SSL перед Commento — Caddy для этого проще nginx, конфиг умещается в несколько строк:

comments.example.com {
    reverse_proxy localhost:8080
}

Если ставите прокси впервые, разберите пошагово в статье про Caddy с авто-SSL на VPS — там же разобраны типичные ошибки с выпуском сертификата.

1. Запустите docker compose up -d, дождитесь, пока Postgres пройдёт инициализацию (первый старт съедает больше CPU и немного больше памяти на создание индексов).
2. Встройте виджет на сайт тегом <script> с указанием data-page-id, проверьте, что комментарии подгружаются без CORS-ошибок в консоли браузера.
3. Через неделю работы посмотрите docker stats и SELECT pg_size_pretty(pg_database_size('commento')); в Postgres — это даст реальную, а не теоретическую картину роста и подскажет, нужно ли поднимать RAM.

Commento vs Isso, Remark42, Disqus — что по ресурсам

Если цель — не конкретно Commento, а вообще self-hosted комментарии без рекламы, стоит сравнить варианты по требованиям к серверу, а не только по фичам:

Isso опирается на SQLite вместо клиент-серверной СУБД, поэтому стартовый порог по памяти у него ниже, чем у Commento, — это разумный вариант, если сайт совсем небольшой и вы не хотите держать отдельный процесс Postgres. Если уже разворачивали Isso и сравниваете на практике, у нас есть отдельный разбор установки Isso на VPS. Remark42 занимает похожую нишу — тоже Go-бинарник без внешней базы, встроенная BoltDB снимает вопрос тюнинга PostgreSQL вообще, ценой чуть менее гибкой модели хранения при очень большом объёме комментариев.

Выбор между ними — это выбор между «чуть больше памяти и гибкости у Commento за счёт полноценного Postgres» и «меньше памяти, меньше что тюнить, но и меньше запаса на рост» у Isso/Remark42. Для блога с несколькими сотнями посетителей в день разница на практике не критична — сервер на 1-2 GB закроет любой из трёх вариантов с запасом.

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