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

MAATRIX

Wekan выглядит как лёгкая замена Trello — просто доска с карточками, что тут может есть много памяти? На практике на VPS с 1 GB RAM установка либо не стартует, либо падает в перезапуск через пару часов работы, и причина не в самом Wekan, а в MongoDB и особенностях реального времени, которые ему нужны для мгновенного обновления досок. Разберём, из чего складывается потребление RAM у Wekan, сколько закладывать под конкретный размер команды и как выставить лимиты в Docker Compose, чтобы не словить OOM на боевом сервере.

Из чего состоит Wekan и почему это не «лёгкая доска» на глазок

Wekan — это приложение на Meteor.js (то есть Node.js под капотом) плюс MongoDB как хранилище. Это не статичный сайт с базой: у Meteor своя модель реального времени, и именно она задаёт базовый уровень потребления памяти сверх того, что кажется логичным для «доски с карточками».

• Процесс Wekan (Node.js/Meteor) — держит DDP-соединение с каждой открытой вкладкой браузера, кэширует подписки на данные (доски, списки, карточки, которые сейчас у кого-то открыты), пересобирает реактивные данные при каждом изменении. Idle-процесс без единого пользователя обычно занимает несколько сотен мегабайт уже на старте — это нормально для Meteor-приложений, а не признак утечки.
• MongoDB — хранит все доски, карточки, чек-листы, комментарии, вложения (если не вынесены на диск отдельно) и историю активности. Собственный процесс со своим бюджетом памяти, который часто забывают посчитать сверх Wekan.
• Oplog и режим replica set — ключевая особенность именно Wekan: чтобы карточки обновлялись у всех участников мгновенно без постоянного опроса базы, Meteor подписывается на oplog MongoDB. А oplog в MongoDB технически существует только в режиме replica set — даже для единственного узла на одном сервере Wekan нужно поднимать Mongo как rs0, а не как обычный standalone-инстанс. Это не опционально «для продакшена», это часть штатной установки, и она добавляет накладные расходы памяти, которых нет у типичных CRUD-приложений на той же MongoDB.

Итого минимальная рабочая связка — это два процесса с раздельным потреблением RAM, и считать нужно сумму, а не одну цифру «на сервер».

Сколько RAM нужно по размеру команды

Официальный минимум, который встречается в обсуждениях вокруг Wekan — от 1 GB RAM, и формально контейнеры на таком объёме действительно стартуют. Но это конфигурация «посмотреть, что это такое», а не рабочий инструмент даже для одного активного пользователя с несколькими досками. Ниже — ориентировочные цифры для разных сценариев использования; это не измеренные бенчмарки, а практический запас с учётом того, как ведёт себя связка Meteor + MongoDB с oplog под нагрузкой.

Практический вывод: 2 GB RAM — это разумный минимум для постоянной работы даже небольшой команды, а не только для теста. Если планируете держать Wekan годами и постепенно расширять число досок и участников, стартуйте с 4 GB — миграция на сервер побольше без простоя обычно возможна, но проще один раз взять с запасом, чем упираться в лимит через месяц.

MongoDB с oplog: где здесь скрытый расход памяти

WiredTiger — движок хранения MongoDB по умолчанию — сам решает, сколько памяти взять под internal cache, и по умолчанию это примерно половина доступной RAM хоста за вычетом 1 GB. На выделенном под базу сервере это разумное поведение. На небольшом VPS, где на той же машине живёт ещё и сам Wekan, это ловушка: MongoDB может забрать себе память, которая нужна Node-процессу под пиковую нагрузку, и тогда падает уже не база, а сам Wekan.

Лечится явным ограничением кэша в конфиге MongoDB:

# mongod.conf
storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 0.5   # для сервера с 2 GB RAM, где Wekan тоже нужен запас

replication:
  replSetName: rs0

После первого запуска реплика-сет нужно инициализировать вручную (или скриптом при первом старте контейнера):

mongosh --eval "rs.initiate({_id: 'rs0', members: [{_id: 0, host: 'localhost:27017'}]})"

Если раньше не разворачивали MongoDB и хочется понять базовую настройку без привязки к Wekan — это отдельная тема, разобранная в статье как установить и настроить MongoDB на VPS. А если база уже работает нестабильно и хочется понять типовые причины — смотрите MongoDB на сервере: частые ошибки и решения, там разобраны в том числе проблемы с oplog размером и репликацией, актуальные и для связки с Wekan.

Docker Compose: готовый файл с лимитами памяти

Большинство инсталляций Wekan разворачивают через Docker Compose с готовым образом wekanteam/wekan и MongoDB рядом. Без явных mem_limit контейнеры могут забрать всю память хоста в момент пиковой нагрузки — с готовым конфигом ниже это исключено, но зато обеспечен предсказуемый OOM вместо тихого зависания сервера:

services:
  wekandb:
    image: mongo:7
    container_name: wekan-db
    command: mongod --oplogSize 128 --replSet rs0
    mem_limit: 1g
    mem_reservation: 512m
    networks:
      - wekan-tier
    volumes:
      - ./data/db:/data/db
    restart: unless-stopped

  wekan:
    image: wekanteam/wekan:latest
    container_name: wekan-app
    mem_limit: 1.5g
    mem_reservation: 768m
    environment:
      - MONGO_URL=mongodb://wekandb:27017/wekan
      - ROOT_URL=https://board.example.com
      - MAIL_URL=smtp://user:pass@smtp.example.com:587/
      - WITH_API=true
    depends_on:
      - wekandb
    networks:
      - wekan-tier
    ports:
      - "3000:8080"
    restart: unless-stopped

networks:
  wekan-tier:
    driver: bridge

Это конфигурация под сервер на 2-3 GB RAM для небольшой команды. Общий принцип выставления mem_limit/mem_reservation и почему лимит впритык к реальному потреблению хуже, чем лимит с запасом 20-30%, разобран в статье как установить и настроить Docker Compose для продакшена на VPS — те же принципы работают для Wekan без изменений.

Проверить фактическое потребление после разворачивания:

docker stats --no-stream wekan-app wekan-db
free -h
docker inspect wekan-app --format='{{.State.OOMKilled}}'

Вложения и активность досок — что реально раздувает базу

Табличные ориентиры выше рассчитаны на «обычное» использование — текстовые карточки, чек-листы, комментарии. То, что заметно увеличивает потребление сверх базового уровня:

• Вложения к карточкам. По умолчанию Wekan хранит файлы в самой MongoDB через GridFS, если не настроено внешнее S3-совместимое хранилище. Это удобно для быстрого старта, но означает, что каждый прикреплённый скриншот или PDF увеличивает объём базы — а с ним и объём, который MongoDB стремится закэшировать в памяти. Если команда активно прикладывает файлы, стоит с самого начала настроить внешнее хранилище (переменные окружения STORAGE_DRIVER, S3_*) вместо GridFS.
• История активности (activity log). Wekan логирует практически каждое действие — перемещение карточки, изменение чек-листа, добавление комментария. На активных досках с десятками участников этот лог растёт быстрее, чем кажется, и со временем стоит проверять размер коллекций в базе.
• Число одновременно открытых вкладок с досками, а не число зарегистрированных пользователей — так же, как и у других Meteor/реалтайм-приложений, память процесса Wekan растёт от активных подписок на данные, а не от общего размера базы пользователей. Человек, который не заходил неделю, почти ничего не стоит.
• Публичные доски и интеграции через API (WITH_API=true) — сами по себе не тяжёлые, но если к API стучится внешний сервис с частым опросом, добавляет постоянную фоновую нагрузку.

Если Wekan используется как внутренний трекер задач наравне с другими self-hosted инструментами команды, разумно сравнить профиль нагрузки с соседними сервисами — например, с Mattermost, у которого похожая модель реального времени поверх WebSocket, только вместо MongoDB — PostgreSQL.

Мониторинг и признаки нехватки памяти

MongoDB и Node.js по-разному реагируют на нехватку памяти, и оба сценария стоит уметь различать до того, как сервис ляжет посреди рабочего дня:

• MongoDB упирается в cacheSizeGB — база не падает резко, а начинает чаще читать с диска вместо кэша, что видно как рост latency у запросов и общее подтормаживание интерфейса при открытии досок с большим числом карточек.
• Node-процесс Wekan съедает всю выделенную память — это уже жёсткий сценарий: ядро Linux убивает процесс через OOM killer, соединения обрываются, открытые доски у всех пользователей одновременно теряют реальное время (WebSocket рвётся), контейнер перезапускается по restart: unless-stopped.

Минимальный набор команд для регулярной проверки:

docker stats --no-stream
free -h
dmesg -T | grep -i "killed process"
mongosh --eval "db.serverStatus().wiredTiger.cache"

Небольшой swap как страховка от внезапного всплеска — разумная мера, но полагаться на него как на основной ресурс для MongoDB не стоит: своп резко увеличивает задержки на дисковых операциях, а WiredTiger и так активно работает с диском при промахах кэша — тормозить эту связку дополнительно не нужно.

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