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

MAATRIX

Taiga выглядит как обычная скрам-доска — бэклог, спринты, канбан, ничего тяжёлого. Но на VPS с 1-2 GB RAM самостоятельно поднятая через Docker Compose Taiga либо не стартует целиком, либо часть контейнеров падает в перезапуск после первого же активного дня команды. Причина в архитектуре: Taiga — это не одно приложение, а связка из семи-восьми отдельных сервисов, и память нужно считать по всем сразу. Разберём, из чего складывается это потребление, сколько закладывать под конкретный размер agile-команды и как выставить лимиты в Docker Compose, чтобы не словить OOM на боевом сервере.

Из чего состоит Taiga и почему считать нужно не один процесс

В отличие от однопроцессных self-hosted инструментов, Taiga изначально спроектирована как набор раздельных сервисов. В официальном docker-compose это выглядит примерно так:

• taiga-back — Django REST API, ядро системы, работает под gunicorn с несколькими воркерами. Обрабатывает всю бизнес-логику: проекты, задачи, спринты, права доступа, вебхуки. Растёт линейно с числом gunicorn-воркеров, которых нужно больше при параллельных запросах.
• taiga-front — собранный статический SPA-фронтенд, отдаётся через nginx как обычные файлы. Сам по себе почти не требует памяти, но всё равно занимает отдельный контейнер в общем бюджете.
• PostgreSQL — основное хранилище проектов, задач, комментариев, истории изменений.
• RabbitMQ — брокер сообщений, через который taiga-back обменивается событиями с сервисом реального времени и ставит в очередь фоновые задачи: письма, импорт/экспорт проектов, вебхуки.
• taiga-events — отдельный процесс на Node.js, слушает очереди RabbitMQ и пушит обновления по WebSocket во все открытые вкладки браузера. Именно за счёт него карточка обновляется у коллеги мгновенно — но это ещё один процесс, требующий памяти пропорционально числу активных вкладок.
• taiga-protected — небольшой сервис, отдаёт защищённые вложения (файлы задач) с проверкой прав доступа, чтобы к ним нельзя было обратиться напрямую мимо авторизации.
• taiga-gateway — nginx, склеивающий все сервисы под одним доменом: маршрутизирует /api, /events, отдаёт статику фронтенда.

Итого при полном развёртывании — это 7-8 контейнеров. Каждый по отдельности лёгкий, но суммарно они делят память хоста, и именно сумма, а не потребление «самой Taiga», определяет, сколько RAM реально нужно серверу.

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

Ниже — ориентировочные цифры для разных сценариев использования. Это не измеренные бенчмарки, а практический запас с учётом накладных расходов на 7-8 отдельных контейнеров и особенностей Django под gunicorn с несколькими воркерами: у конкретной инсталляции цифры сдвинутся в зависимости от числа воркеров, объёма вложений и частоты импорта/экспорта проектов.

Формальные системные требования, которые встречаются в обсуждениях вокруг Taiga, довольно скромные — на 2 GB RAM все контейнеры технически стартуют. Но это конфигурация «посмотреть», а не рабочий инструмент даже для небольшой команды: при первом же дне, когда несколько человек одновременно двигают карточки по спринту и получают обновления в реальном времени, легко упереться в лимит, потому что параллельно работают gunicorn, PostgreSQL, RabbitMQ и Node.js-процесс событий. Для постоянной работы закладывайте от 3-4 GB даже под небольшую команду, а если планируете растить число проектов — стартуйте с 6 GB, чтобы не мигрировать на больший сервер через пару месяцев.

PostgreSQL под Taiga: тюнинг под ограниченную память

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

Ключевые параметры в postgresql.conf для сервера на 4 GB RAM, где под Taiga выделена примерно четверть-треть памяти:

# postgresql.conf, для базы на выделенных ~1 GB из общих 4 GB хоста
shared_buffers = 256MB
effective_cache_size = 768MB
work_mem = 8MB
maintenance_work_mem = 64MB
max_connections = 50

max_connections стоит держать умеренным — taiga-back обращается к базе пулом соединений из gunicorn-воркеров, и agile-команде из полусотни человек за глаза хватает пары десятков одновременных соединений, а не сотни по умолчанию, которая только зарезервирует лишнюю память под каждое подключение.

Если PostgreSQL поднимается впервые — базовая установка разобрана в статье PostgreSQL: установка и настройка на VPS, а разбор shared_buffers, work_mem и остальных параметров памяти — в статье тюнинг PostgreSQL на VPS. Те же принципы работают для базы Taiga без изменений, разница только в масштабе.

RabbitMQ и taiga-events: скрытая цена реального времени

RabbitMQ на новом инстансе сам по себе не тяжёлый — процесс Erlang VM обычно держит около 100-150 MB в простое, это ориентир, а не измеренное число для вашей версии. Но с ростом числа очередей и неподтверждённых (unacked) сообщений память растёт, и на маленьком VPS это стоит ограничить явно:

# через rabbitmqctl, ограничить память до 40% RAM хоста
rabbitmqctl set_vm_memory_high_watermark 0.4

taiga-events — второй источник накладных расходов, о котором часто забывают при сайзинге. Его память растёт не от размера проектов в базе, а от числа одновременно открытых вкладок браузера с активной подпиской на обновления: команда, где половина держит доску открытой весь день, требует заметно больше памяти на процесс, чем та же команда, открывающая Taiga раз в день свериться со спринтом.

Практический вывод: если команда небольшая и мгновенные обновления не критичны (можно пережить ручной refresh), на совсем скромном сервере есть смысл временно отключить taiga-events, а RabbitMQ оставить только для фоновых задач — это снижает базовый уровень потребления памяти ценой части удобства.

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

Без явных mem_limit контейнеры Taiga могут занять всю доступную память хоста в момент пиковой нагрузки — с лимитами ниже это исключено, но взамен вы получаете предсказуемый и диагностируемый OOM вместо тихого зависания всей связки сервисов:

services:
  taiga-db:
    image: postgres:15-alpine
    mem_limit: 900m
    mem_reservation: 500m
    environment:
      - POSTGRES_DB=taiga
      - POSTGRES_USER=taiga
      - POSTGRES_PASSWORD=changeme
    volumes:
      - ./data/db:/var/lib/postgresql/data
    restart: unless-stopped

  taiga-rabbitmq:
    image: rabbitmq:3.12-alpine
    mem_limit: 300m
    mem_reservation: 150m
    restart: unless-stopped

  taiga-back:
    image: taigaio/taiga-back:latest
    mem_limit: 900m
    mem_reservation: 500m
    environment:
      - POSTGRES_HOST=taiga-db
      - RABBITMQ_HOST=taiga-rabbitmq
    depends_on: [taiga-db, taiga-rabbitmq]
    volumes:
      - ./data/media:/taiga-back/media
    restart: unless-stopped

  taiga-async:
    image: taigaio/taiga-back:latest
    command: ["/taiga-back/docker/async_entrypoint.sh"]
    mem_limit: 400m
    mem_reservation: 200m
    depends_on: [taiga-db, taiga-rabbitmq]
    restart: unless-stopped

  taiga-events:
    image: taigaio/taiga-events:latest
    mem_limit: 300m
    mem_reservation: 150m
    depends_on: [taiga-rabbitmq]
    restart: unless-stopped

  taiga-protected:
    image: taigaio/taiga-protected:latest
    mem_limit: 150m
    restart: unless-stopped

  taiga-front:
    image: taigaio/taiga-front:latest
    mem_limit: 100m
    restart: unless-stopped

  taiga-gateway:
    image: nginx:alpine
    mem_limit: 100m
    ports: ["9000:80"]
    depends_on: [taiga-back, taiga-front, taiga-events, taiga-protected]
    restart: unless-stopped

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

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

С семью-восемью контейнерами диагностика сложнее, чем с одним приложением: важно понять, какой именно сервис упирается в лимит, прежде чем увеличивать RAM всему серверу целиком.

docker stats --no-stream
free -h
dmesg -T | grep -i "killed process"
docker inspect taiga-back --format='{{.State.OOMKilled}}'

Типичные признаки по сервисам:

• taiga-back упирается в лимит — растут задержки ответа API, интерфейс подтормаживает при открытии досок и бэклога. Обычно решается либо увеличением mem_limit, либо уменьшением числа gunicorn-воркеров, если сервер и так на грани.
• PostgreSQL — при нехватке памяти под shared_buffers и системный page cache база чаще читает с диска, что заметно как рост latency на тяжёлых запросах (фильтры по эпикам, поиск по задачам), а не как явный сбой.
• RabbitMQ упирается в vm_memory_high_watermark — брокер переходит в защитный режим и блокирует публикацию новых сообщений, из-за чего фоновые задачи (письма, вебхуки) начинают зависать в очереди, хотя сам сайт продолжает открываться.
• taiga-events съедает всю выделенную память — WebSocket-соединения обрываются у всех пользователей одновременно, доски перестают обновляться в реальном времени, но остальная система при этом может продолжать работать нормально — это самый безобидный по последствиям, но самый заметный пользователям сбой.

Экспорт и импорт проектов (в том числе из Jira, Trello или другой Taiga через встроенные импортеры) — операции, которые кратковременно, но заметно поднимают потребление памяти у taiga-back и taiga-async, потому что весь проект со всей историей задач собирается и сериализуется в памяти процесса. На небольшом сервере разумно не запускать такие операции параллельно с рабочим днём активной команды, а планировать их на менее нагруженное время.

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