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

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

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

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

Каждый сервис deploy/local/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
minio MINIO_MEM_LIMIT 256m
minio-bootstrap — одноразовый, завершается после старта
caddy — без лимита (обычно десятки МБ)
guide — 64m
Итого потолков ≈ 3,1 ГиБ

Вход людей и рабочие места (idp, harness)

Сервис Переменная По умолчанию
keycloak-db PG_MEM_LIMIT 256m
keycloak KEYCLOAK_MEM_LIMIT 768m
realm-render, harness-image — одноразовые, завершаются после старта
harness-launcher — 128m
harness-docker-proxy — 64m
Итого потолков ≈ 1,2 ГиБ
контейнер рабочего места, на каждого активного человека HARNESS_MEM_LIMIT_MB 1536 МиБ

Контейнер рабочего места засыпает после HARNESS_IDLE_MINUTES (30) без запросов, поэтому память считают по числу одновременно работающих людей.

PG_MEM_LIMIT — общий

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

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

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

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

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

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

Как считать:

  • Сумма потолков — верхняя оценка. В покое сервисы потребляют заметно меньше, но под нагрузкой к потолку подходят memory-db, memory-service и keycloak. Фактическое потребление смотрите docker stats.

  • Оставьте не меньше 1 ГиБ на ОС, Docker, файловый кэш и сборку образов: tools/compose build на хосте кратковременно требует памяти и CPU больше, чем работающий стек. На машине с 2 vCPU сборку стоит выполнять заранее, до переключения (см. Обновление и миграции).

  • Swap не заменяет память, но спасает от OOM во время сборки и пиков.

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

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

Диск

Что растёт Где Оценка и управление
Журнал событий Control Plane control_plane_db Растёт линейно с работой; :archive уменьшает горячую таблицу, но не общий размер тома; физически освобождает только :prune
Память: вектора memory_db Эмбеддинг размерности 1536 во float4 — 6 КиБ на чанк; только вектора 100 тыс. чанков — около 600 МБ, плюс индекс, текст и граф
Память: граф, наблюдения, трассы memory_db Растёт с объёмом загруженных знаний и числом сборок контекста
Содержимое артефактов platform_minio (том MinIO) Объём файлов, сданных в артефакты задач
Образы и кэш сборки Docker Несколько ГБ на релиз; docker image prune, docker builder prune
Логи контейнеров Docker Без ротации растут неограниченно — см. Мониторинг
Бэкапы /opt/taimen/backups Дампы × срок хранения; выносите за пределы хоста 
docker system df -v | head -40
tools/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 Один контейнер; горизонтальное масштабирование в deploy/local/compose.yml не описано
Базы Каждая — отдельный контейнер PostgreSQL 16 на этом же хосте. Для базы памяти из расширений нужен только pgvector (pg_trgm рекомендуется), графового расширения и суперпользователя сервису не нужно — подойдёт и управляемый PostgreSQL с pgvector. Расширения создаёт шаг подготовки базы, сервис работает владельцем своей базы
Миграции Индексы строятся не CONCURRENTLY — на больших таблицах нужно окно обслуживания
Retention журнала Планировщика нет: :archive запускает оператор

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

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

Runner-хост

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

Лимиты задаются в compose-файле исполнителя: cpus и mem_limit. Ориентир — 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 Интервал опроса очереди, секунды

См. также