Перейти к содержанию

Ресурсы и масштабирование

Сколько CPU, памяти и диска нужно установке Taimen, какие лимиты заданы в compose.yml, как их менять и где у платформы пределы масштабирования. Статья для инженера, который выбирает машину и планирует рост.

Лимиты памяти контейнеров

Каждый сервис корневого compose.yml имеет mem_limit, заданный переменной окружения со значением по умолчанию. Значение — потолок: при его превышении ядро убивает процесс контейнера (OOM), Docker перезапускает его по restart: unless-stopped.

Ядро и периметр (core, edge)

Сервис Переменная По умолчанию
iam-db PG_MEM_LIMIT 256m
iam-service IAM_MEM_LIMIT 256m
control-plane-db PG_MEM_LIMIT 256m
control-plane-api CP_MEM_LIMIT 512m
control-plane-worker CP_WORKER_MEM_LIMIT 256m
context-adapter CP_WORKER_MEM_LIMIT 256m
memory-db MEMORY_DB_MEM_LIMIT 512m
memory-service MEMORY_MEM_LIMIT 512m
caddy — без лимита (обычно десятки МБ)
Итого потолков ≈ 2,8 ГиБ

Панель платформы (platform)

Сервис Переменная По умолчанию
platform-db PG_MEM_LIMIT 256m
platform-redis REDIS_MEM_LIMIT 128m
keycloak KEYCLOAK_MEM_LIMIT 768m
minio MINIO_MEM_LIMIT 256m
platform-api PLATFORM_API_MEM_LIMIT 512m
platform-web PLATFORM_WEB_MEM_LIMIT 512m
realm-render, minio-bootstrap, platform-migrations — одноразовые, завершаются после старта
Итого потолков ≈ 2,4 ГиБ

Прочие профили

Профиль Сервисы и потолки Итого
policy policy-db 256m (PG_MEM_LIMIT), openfga 256m (OPENFGA_MEM_LIMIT), policy-service и policy-worker по 256m (POL_MEM_LIMIT) ≈ 1 ГиБ
entitlement entitlement-db 256m, entitlement-service 256m (ENT_MEM_LIMIT) 512 МиБ
demo support-bot 256m (SUPPORT_MEM_LIMIT) 256 МиБ
узел fleet рядом со стеком fleet-node 128m, docker-proxy 64m, агент git-connector — по resources.memoryMb описания (384 МиБ в пакете selfdev) ≈ 576 МиБ

PG_MEM_LIMIT — общий

Одна переменная задаёт потолок всем базам на образе postgres:16-alpine. У memory-db (граф и вектора) свой потолок MEMORY_DB_MEM_LIMIT, потому что ей нужно больше всех.

Как изменить лимит

Задайте переменную в .env и пересоздайте сервис:

echo 'MEMORY_DB_MEM_LIMIT=1g' >> .env
docker compose up -d memory-db
docker stats --no-stream        # фактическое потребление против лимита

Рекомендуемые конфигурации хоста

Состав vCPU RAM Swap Диск Комментарий
core edge (минимум) 2 4 ГиБ 2 ГиБ 40 ГБ Координация, IAM, память на небольших базах знаний
core platform edge 2 6 ГиБ 2 ГиБ 80 ГБ Проверенная конфигурация для ядра с панелью
core platform edge + вертикальный пакет 4 8 ГиБ 4 ГиБ 100 ГБ С исполнителями пакета и экспериментальными профилями

Как считать:

  • Сумма потолков — верхняя оценка. В покое сервисы потребляют заметно меньше, но под нагрузкой к потолку подходят memory-db, memory-service и keycloak. Фактическое потребление смотрите docker stats.
  • Оставьте не меньше 1 ГиБ на ОС, Docker, файловый кэш и сборку образов: docker compose build на хосте кратковременно требует памяти и CPU больше, чем работающий стек. На машине с 2 vCPU сборку стоит выполнять заранее, до переключения (см. Обновление и миграции).
  • Swap не заменяет память, но спасает от OOM во время сборки и пиков.

Keycloak — самый требовательный к памяти

Keycloak работает на JVM, стартует до минуты и получает самый высокий потолок в стеке (768m). На машине с 4 ГиБ профиль platform поднимать не стоит.

Диск

Что растёт Где Оценка и управление
Журнал событий Control Plane control_plane_db Растёт линейно с работой; :archive уменьшает горячую таблицу, но не общий размер тома; физически освобождает только :prune
Память: вектора memory_db Эмбеддинг размерности 1536 во float4 — 6 КиБ на чанк; только вектора 100 тыс. чанков — около 600 МБ, плюс индекс, текст и граф
Память: граф, наблюдения, трассы memory_db Растёт с объёмом загруженных знаний и числом сборок контекста
Документы платформы platform_minio Объём загруженных файлов
Образы и кэш сборки Docker Несколько ГБ на релиз; docker image prune, docker builder prune
Логи контейнеров Docker Без ротации растут неограниченно — см. Мониторинг
Бэкапы /opt/taimen/backups Дампы × срок хранения; выносите за пределы хоста 
docker system df -v | head -40
docker compose exec control-plane-db psql -U control_plane -d control_plane \
  -c "SELECT relname, pg_size_pretty(pg_total_relation_size(relid)) FROM pg_catalog.pg_statio_user_tables ORDER BY pg_total_relation_size(relid) DESC LIMIT 10"

Пределы масштабирования

Платформа рассчитана на вертикальное масштабирование одного хоста. Что важно знать:

Компонент Ограничение
context-adapter Singleton: единственность держится advisory lock в базе. Второй экземпляр не ускорит доставку. Per-tenant изоляция изолирует отказы (один запаркованный tenant не блокирует остальных), а не даёт параллелизм
control-plane-api Один контейнер; горизонтальное масштабирование в compose.yml не описано
Базы Каждая — отдельный контейнер PostgreSQL 16 на этом же хосте. Для memory-db нужны расширения Apache AGE и pgvector, которых у управляемых PostgreSQL обычно нет
Миграции Индексы строятся не CONCURRENTLY — на больших таблицах нужно окно обслуживания
Retention журнала Планировщика нет: :archive запускает оператор

Если хост перестаёт справляться, по порядку:

  1. Поднимите MEMORY_DB_MEM_LIMIT, MEMORY_MEM_LIMIT, CP_MEM_LIMIT.
  2. Архивируйте журнал Control Plane.
  3. Вынесите исполнителей и экспериментальные профили на другие машины.
  4. Перейдите на машину с большим числом vCPU и памяти (перенос — через Резервное копирование).

Runner-хост

Кодовый агент (Node.js + модель через API поставщика) потребляет много памяти в пиках, особенно при сборке и тестах внутри рабочей копии.

В deploy/runner/docker/compose.yml каждому исполнителю задано cpus: 2 и mem_limit: 4g, тестовым базам — 512m (db-test) и 768m (memory-db-test, данные в tmpfs). Два исполнителя с тестовыми базами — это около 10 ГБ потолков: машине нужно 8–12 ГиБ RAM и 4 vCPU.

Лимиты задаются в юните или drop-in limits.conf: CPUQuota, MemoryHigh (мягкий порог, выше которого ядро начинает отбирать память), MemoryMax (жёсткий потолок на весь cgroup, включая дочерние процессы агента), IOWeight.

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

Если на одной машине несколько исполнителей, сумма их MemoryMax (или mem_limit) должна укладываться в физическую память за вычетом ОС и соседних сервисов. Иначе два тяжёлых прогона одновременно выводят машину в OOM: ядро убивает процесс, systemd или Docker его перезапускает, а run закрывается с failure_reason=restart_recovery. Если задача повторно упирается в потолок, её нужно выполнять на машине крупнее, а не поднимать потолок до уровня, при котором страдают соседи.

Прочие параметры потребления исполнителя:

Переменная По умолчанию Смысл
CONTROL_PLANE_AGENT_MAX_WORKSPACES 8 Сколько рабочих копий хранить на диске
CONTROL_PLANE_CLAUDE_TIMEOUT 3600 Предел одного хода кодового агента, секунды
CONTROL_PLANE_AGENT_POLL 5 Интервал опроса очереди, секунды

См. также