Сколько RAM нужно для Wiki.js

MAATRIX

Wiki.js выглядит легковесно на скриншотах — чистый интерфейс, быстрый поиск, редактор в стиле Notion. Но это не статический сайт и не PHP-скрипт, который просыпается только на запрос: под капотом постоянно работающий процесс Node.js плюс полноценная СУБД, а часто ещё и Git-синхронизация с внешним репозиторием. Разберём, из чего реально складывается расход RAM у этой связки и сколько закладывать под свой сценарий — от личной вики на пару десятков страниц до базы знаний команды с LDAP и Git-версионированием.

Из чего складывается память у Wiki.js

Wiki.js — Node.js-приложение (Express + Vue.js на фронтенде), которое официально требует внешнюю СУБД: PostgreSQL, MySQL, MariaDB или MS SQL Server (SQLite поддерживается, но только для тестов — разработчики прямо не рекомендуют её для продакшена). Это принципиально другая модель памяти по сравнению с PHP-движками вроде BookStack или Confluence:

• Node.js-процесс держит в памяти не только код приложения, но и V8-хип — объекты, кэш скомпилированных модулей, активные сессии. В отличие от PHP-FPM, который порождает и убивает воркеров под каждый запрос, здесь один долгоживущий процесс (если не включена кластеризация), и его память со временем растёт, а не сбрасывается между запросами.
• PostgreSQL (или другая СУБД) — хранит страницы, ревизии, права, метаданные пользователей и, если не подключён внешний поисковый движок, полнотекстовый индекс.
• Поисковый движок — Wiki.js из коробки использует базовый поиск через саму БД, но умеет переключаться на Elasticsearch, Algolia, PostgreSQL full-text (более тяжёлый режим) или Azure Cognitive Search. Каждый из этих вариантов по-разному нагружает память: встроенный поиск дешевле, внешний Elasticsearch — это отдельный сервис со своим аппетитом.
• Git-модуль синхронизации (если включён) — периодически клонирует и синхронизирует контент с внешним репозиторием через дочерние git-процессы.

Официальная документация Wiki.js не даёт точных цифр по RAM — там указаны только требования к версии Node.js и СУБД, а не лимиты памяти. Поэтому дальше — инженерный расчёт по компонентам, а не выдержка из мануала: у вас цифры сдвинутся в зависимости от объёма контента, числа одновременных редакторов и того, включена ли Git-синхронизация.

Малая вики: личный проект или команда до 15–20 человек

Для личной базы знаний, документации небольшого проекта или команды до 15–20 человек с несколькими сотнями страниц типичная раскладка на сервере с 1–2 ГБ RAM выглядит так:

1 ГБ технически хватает для теста и знакомства с движком, но без запаса — любой всплеск (массовый импорт страниц, тяжёлый поиск, одновременное сохранение у нескольких пользователей) может упереться в своп. Для стабильного продакшена даже небольшой личной вики разумный минимум — 2 ГБ: это даёт запас и Node.js, и PostgreSQL без постоянного балансирования на грани.

# docker-compose.yml — минимальная связка на 2 ГБ RAM
version: "3"
services:
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: wiki
      POSTGRES_USER: wikijs
      POSTGRES_PASSWORD: changeme
    volumes:
      - db-data:/var/lib/postgresql/data
    restart: unless-stopped

  wiki:
    image: ghcr.io/requarks/wiki:2
    depends_on:
      - db
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: changeme
      DB_NAME: wiki
    ports:
      - "3000:3000"
    restart: unless-stopped

volumes:
  db-data:

Перед сервером стоит поставить обратный прокси с SSL — как это настроить на Ubuntu, разобрано в статье Nginx как reverse-proxy на VPS.

Средняя команда: активная документация и поиск

Когда вики становится рабочим инструментом отдела или компании — десятки активных редакторов, тысячи страниц, регулярный поиск по содержимому, — картина меняется по двум причинам.

Во-первых, Node.js-процесс Wiki.js не изолирует запросы друг от друга так, как это делает PHP-FPM: чем больше одновременных операций (рендеринг Markdown, генерация превью, обработка загруженных файлов), тем выше пиковое потребление хипа V8. Во-вторых, растёт БД: при нескольких тысячах страниц с историей ревизий PostgreSQL начинает заметно выигрывать от увеличенного shared_buffers, иначе поиск и списки страниц начинают чаще ходить на диск.

Для 20–50 активных пользователей с постоянной работой над контентом ориентир — 4 ГБ RAM:

• Node.js — 400–800 МБ под нагрузкой (несколько параллельных рендерингов и загрузок файлов);
• PostgreSQL — 500 МБ–1 ГБ с адекватным shared_buffers;
• запас под ОС, бэкапы и возможный внешний поисковый движок.

Если команда подключает LDAP или корпоративный OAuth2/SAML для единого входа — это не добавляет заметной постоянной нагрузки на память (модули аутентификации Wiki.js лёгкие), но стоит учитывать, что LDAP-запросы с большим числом групп могут временно увеличивать расход при синхронизации прав.

Git-синхронизация: за что платите памятью

Одна из фирменных особенностей Wiki.js — модуль синхронизации контента с Git-репозиторием: каждое изменение страницы можно автоматически коммитить во внешний Git (GitHub, GitLab, самостоятельный Gitea), получая полноценную историю версий вне БД. Это удобно, но не бесплатно с точки зрения ресурсов:

• каждая синхронизация запускает дочерний git-процесс — кратковременный всплеск памяти и CPU, обычно 30–80 МБ на операцию в зависимости от размера репозитория;
• при первом подключении к большому существующему репозиторию Wiki.js клонирует его целиком — на сервере с 1 ГБ RAM клонирование репозитория с историей в сотни коммитов и вложениями может временно съесть весь свободный запас;
• при частых автосохранениях (например, синхронизация после каждого редактирования) на активно используемой вики дочерние git-процессы могут накладываться друг на друга, если предыдущая синхронизация не успела завершиться.

На практике для сервера от 2 ГБ это не проблема — всплески кратковременные и не держат память постоянно. Но если вы уже держите отдельный Gitea или самостоятельный Git-сервер для хранения контента вики, стоит закладывать RAM отдельно и под него — расчёт разобран в статье сколько RAM нужно для Gitea.

Если Git-синхронизация не нужна (версионирование и так работает через встроенную историю ревизий в БД), модуль можно не включать вовсе — это самый простой способ сэкономить память без потери функциональности для большинства команд.

PostgreSQL: буфер под конкретный объём базы

PostgreSQL — рекомендуемая и де-факто основная СУБД для Wiki.js, и именно её настройка чаще всего определяет, насколько отзывчиво работает поиск и списки страниц при росте базы.

Ключевой параметр — shared_buffers, доля оперативной памяти, которую PostgreSQL держит под кэш часто используемых страниц данных:

# postgresql.conf
shared_buffers = 256MB          # для сервера с 2 ГБ RAM
effective_cache_size = 1GB      # ориентир ОС+кэш, не жёсткий лимит
work_mem = 8MB
maintenance_work_mem = 64MB

Общее правило — shared_buffers около 25% от общей RAM сервера, если PostgreSQL не единственный тяжёлый сервис на машине, иметь смысл брать меньшую долю. Подробный разбор установки и первичной настройки PostgreSQL на VPS — в статье как установить и настроить PostgreSQL на VPS.

Отдельный нюанс именно для Wiki.js: если вы включаете полнотекстовый поиск через PostgreSQL (а не встроенный базовый поиск или внешний Elasticsearch), индексы tsvector добавляют объём к базе и нагрузку при каждой записи страницы — на больших вики это ощутимее, чем сам факт хранения текста.

Node.js: лимит heap и типичный OOM

Node.js по умолчанию ограничивает размер old space V8 — на большинстве современных версий это не жёсткая проблема для Wiki.js при разумных объёмах контента, но на серверах с очень малым запасом RAM (1 ГБ и меньше) возможна обратная ситуация: не Node.js упирается в собственный лимит, а ядро ОС убивает процесс через OOM-killer раньше, чем V8 успевает среагировать на нехватку памяти.

Если нужно явно ограничить память Node.js (например, чтобы он не боролся за последние мегабайты с PostgreSQL на тесном сервере), лимит heap задаётся через переменную окружения:

# в docker-compose.yml, сервис wiki
environment:
  NODE_OPTIONS: "--max-old-space-size=512"

Ставить лимит ниже реальных потребностей вредно — приложение начнёт чаще запускать сборку мусора (GC), это лишняя нагрузка на CPU, а при действительно недостаточном лимите — падение с ошибкой JavaScript heap out of memory в логах контейнера. Проверить, во что процесс упирается на практике, проще всего через docker stats в момент пиковой нагрузки — активного редактирования или полнотекстового поиска несколькими пользователями одновременно.

Общий подход к тому, какой запас памяти закладывать сверх расчётного минимума на любом сервисе, — в статье сколько оперативной памяти закладывать с запасом.

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