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

MAATRIX

Если вы собрали статический сайт на Hugo, Jekyll или Astro и уперлись в единственный минус этого подхода — негде оставить комментарий, — Isso почти наверняка первое, что вам посоветуют. Это не Disqus с его рекламой и слежкой за читателями, а маленький Python-сервис, который вы разворачиваете сами и который отдаёт комментарии в виде простого JS-виджета. Вопрос «сколько под него закладывать VPS» решается быстро: Isso — один из самых лёгких self-hosted сервисов в принципе, и переплачивать за память под него не за что.

Что такое Isso и почему он такой лёгкий

Isso написан на Python поверх микрофреймворка bottle — без Django, без DI-контейнеров, без ORM с ленивой загрузкой связей. Хранилище — SQLite, файл на диске, а не отдельный демон вроде MySQL или PostgreSQL. Никакого Node.js на сервере не требуется: JS нужен только в браузере читателя, чтобы отрисовать виджет и подтянуть комментарии через API.

Сама архитектура — это один Python-процесс (или несколько воркеров, если решите масштабировать), который слушает локальный порт и отвечает на запросы вида «дай комментарии к этой странице» и «сохрани новый комментарий». Никакого фонового индексатора, никакой очереди задач, никакого Redis по умолчанию. Это принципиально отличает Isso от более тяжёлых self-hosted альтернатив на PHP/Symfony или Node.js-стеке — там даже в простое крутится набор процессов на десятки-сотни мегабайт, здесь по сути один компактный Python-процесс.

Оборотная сторона лёгкости — Isso не пытается быть платформой: нет соцвходов (только опциональная привязка Gravatar по email), модерация делается через простую очередь с подтверждением по ссылке в письме. Для личного блога или небольшого технического сайта этого достаточно с запасом.

Из чего складывается расход памяти

Реальное потребление RAM на сервере с Isso — это сумма нескольких небольших компонентов, и ни один из них не тянет за собой отдельный тяжёлый демон:

• Python-процесс Isso — интерпретатор CPython плюс загруженные библиотеки (bottle, драйвер sqlite3 из стандартной библиотеки, misaka для рендеринга markdown в комментариях, itsdangerous для подписи cookie) в простое обычно держат порядка 30-60 МБ RSS на один рабочий процесс. Это заметно меньше, чем типичный воркер PHP-FPM под фреймворком или процесс Node.js с загруженным Express-приложением.
• SQLite — не отдельный процесс, а библиотека, встроенная прямо в Python-процесс Isso. База — файл comments.db на диске; для блога с несколькими тысячами комментариев это обычно считаные мегабайты на диске, и SQLite не держит её целиком в оперативной памяти — читает нужные страницы через файловый кеш ОС.
• Дополнительные воркеры — если вынесете Isso под gunicorn/uWSGI с несколькими воркер-процессами (для сайта с заметным трафиком на страницы комментариев), каждый добавочный воркер — это ещё один Python-процесс с приложением, то есть плюс те же 25-40 МБ.
• Nginx перед Isso — если, как рекомендуется, ставите nginx реверс-прокси с TLS, это 5-10 МБ базово плюс 1-3 МБ на воркер-процесс nginx.
• SMTP-уведомления о новых комментариях — используют стандартный smtplib внутри того же процесса, разовая сетевая операция, отдельной памяти не требует.
• ОС и системные службы — минимальный Debian/Ubuntu без графики съедает 100-150 МБ на ядро, systemd, cron, sshd — это база, которая есть независимо от того, что вы на сервер поставили.

Итог: сам Isso в этой сумме — едва ли не самая маленькая строчка. Основной расход памяти на типичном VPS под него — это операционная система и вспомогательные службы, а не сам сервис комментариев.

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

Цифры ниже — практический ориентир, а не гарантия: конкретное потребление зависит от версии Python, числа воркеров, настроек guard-модуля и от того, что ещё крутится на том же VPS (например, сборка статики Hugo/Jekyll).

Для абсолютного большинства блогов на статике формально хватает и 512 МБ: сам Isso в простое почти не заметен на фоне ОС. Но на практике я рекомендую 1 ГБ — не из-за Isso как такового, а потому что на том же VPS обычно нужно что-то ещё: собрать сайт генератором (Hugo при сборке кратковременно потребляет заметно больше базового простоя, это разобрано в статье про требования Hugo к памяти), развернуть Let's Encrypt, гонять cron-бэкап базы комментариев. Запас сверху убирает риск словить OOM, когда несколько этих задач совпадут по времени.

Установка Isso и systemd-сервис

Разворачивать Isso лучше в изолированном виртуальном окружении, а не системным pip — так проще обновлять версию без риска сломать системный Python:

sudo apt update && sudo apt install -y python3-venv python3-dev build-essential libsqlite3-dev
sudo mkdir -p /opt/isso && sudo chown $USER:$USER /opt/isso
python3 -m venv /opt/isso/venv
/opt/isso/venv/bin/pip install --upgrade pip
/opt/isso/venv/bin/pip install isso

Минимальный isso.cfg (пример под один блог):

[general]
dbpath = /opt/isso/comments.db
host = https://blog.example.com/
notify = smtp
gravatar = true
reply-notifications = true

[server]
listen = http://127.0.0.1:8080/
reload = off
profile = off

[smtp]
username =
password =
host = localhost
port = 587
security = starttls
to = you@example.com
from = isso@example.com

[guard]
enabled = true
ratelimit = 2
direct-reply = 3

[moderation]
enabled = true
purge-after = 30d

Секция [guard] — это встроенная защита от спама: rate-limit по IP и ограничение на глубину прямых ответов без модерации. Никаких внешних антиспам-сервисов Isso не вызывает, а значит и лишней сетевой нагрузки или задержки на каждый комментарий это не добавляет.

У Isso есть собственный встроенный HTTP-сервер, которого хватает для личного блога и сайта с нечастыми комментариями — именно его вызывает команда isso run. Для заметно более высокого трафика на страницы с комментариями в документации рекомендуют вынести приложение под полноценный WSGI-сервер вроде uWSGI (Isso — обычное WSGI-приложение, так что gunicorn тоже подойдёт), но для сценариев из таблицы выше встроенного сервера обычно достаточно.

Systemd-юнит для автозапуска (/etc/systemd/system/isso.service):

[Unit]
Description=Isso comment server
After=network.target

[Service]
User=isso
Group=isso
WorkingDirectory=/opt/isso
ExecStart=/opt/isso/venv/bin/isso -c /opt/isso/isso.cfg run
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo useradd -r -s /usr/sbin/nologin isso
sudo chown -R isso:isso /opt/isso
sudo systemctl daemon-reload
sudo systemctl enable --now isso
sudo systemctl status isso

Nginx перед Isso: reverse proxy и встраивание на сайт

Isso слушает только локальный порт — наружу его открывать не нужно, TLS и внешний домен берёт на себя nginx. Если вы ещё не настраивали nginx как реверс-прокси, общий порядок с proxy_pass, заголовками и HTTPS через Let's Encrypt подробно разобран в статье про установку nginx как реверс-прокси на Ubuntu 24.04 — здесь только специфика под Isso:

server {
    listen 443 ssl http2;
    server_name blog.example.com;

    ssl_certificate     /etc/letsencrypt/live/blog.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/blog.example.com/privkey.pem;

    location /isso/ {
        proxy_pass http://127.0.0.1:8080/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location / {
        root /var/www/blog.example.com;
        try_files $uri $uri/ =404;
    }
}

Сам Isso раздаёт свой JS-клиент по тому же адресу — отдельно копировать isso.js на статику не нужно. В шаблон страницы (например, в layouts/partials/comments.html для Hugo или аналогичный partial для Jekyll) добавляется:

<script data-isso="https://blog.example.com/isso/"
        src="https://blog.example.com/isso/js/embed.min.js"></script>
<section id="isso-thread"></section>

Если сайт собран Hugo и деплоится тем же процессом, что описан в статье про установку Hugo на Ubuntu 24.04, это единственная правка в шаблоне — сама сборка статики с Isso никак не связана и памятью с ним не делится, они просто оба крутятся на одном VPS.

Модерация и импорт из Disqus

Если переезжаете с Disqus, у Isso есть команда isso import, которая читает XML-экспорт Disqus и переносит комментарии в локальную SQLite-базу — операция разовая и по памяти не отличается от обычной записи комментариев, разве что занимает больше времени на большом архиве.

Новые комментарии по умолчанию можно требовать на модерацию ([moderation] enabled = true) — тогда автору сайта на email из секции [smtp] приходит письмо со ссылкой «одобрить» или «удалить». Это синхронная операция внутри того же процесса, отдельной очереди задач не создаётся, так что модерация не добавляет нагрузки сверх посчитанной выше.

Для защиты панели модерации и самого API от перебора имеет смысл поставить fail2ban поверх логов nginx — как это настроить в целом, описано в статье про fail2ban для nginx. Сам fail2ban — это ещё один лёгкий процесс на несколько мегабайт, в бюджет 512 МБ - 1 ГБ он укладывается без проблем.

Что делать, если памяти всё же не хватает

На практике для одиночного Isso нехватка RAM — редкость: скорее вы упрётесь в неё из-за чего-то другого на том же VPS (сборка сайта, бэкап, второй сервис). Если видите тревожные признаки — dmesg | grep -i oom показывает убитые процессы, free -h стабильно держит доступную память около нуля — порядок действий обычный:

free -h
systemctl status isso
ps aux --sort=-%mem | head -10

Если основной потребитель — не Isso, а что-то ещё, разбирать стоит именно этот процесс: общий порядок диагностики и решений при нехватке памяти на VPS разобран в статье что делать при нехватке RAM. Если свободной памяти мало эпизодически (например, во время ночной сборки сайта и бэкапа одновременно), может выручить своп — как посчитать разумный размер под конкретный объём RAM, смотрите в материале про правильный размер swap для VPS. Для самого Isso снижать особо нечего — он и так работает одним лёгким процессом, но если завели несколько воркеров под ним «на всякий случай», первый шаг — вернуться к одному.

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