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

MAATRIX

Библиотека на несколько терабайт, половина файлов в H.264 и весит вдвое больше, чем могла бы, а перегонять всё вручную через HandBrake — работа на месяцы. Tdarr решает это автоматически: смотрит на видеотеку, находит файлы под заданные правила (кодек, битрейт, контейнер, здоровье файла) и раздаёт перекодирование по одному или нескольким воркерам, пока вы спите. Вопрос «сколько же памяти заложить» здесь сложнее, чем для обычного медиасервера — потому что Tdarr это не один процесс, а связка Server и Node, и каждый параллельный воркер транскодирования — это отдельный ffmpeg со своим аппетитом к RAM. Разберём по компонентам, чтобы не гадать.

Архитектура Tdarr: Server и Node — разная нагрузка на разных ролях

Tdarr построен на двух ролях, которые можно развернуть и на одной машине, и раскидать по нескольким:

• Tdarr Server — веб-интерфейс, очередь задач, база данных со сканированной библиотекой и статусами файлов. Сам по себе не транскодирует — только раздаёт работу и хранит состояние.
• Tdarr Node — рабочий процесс, который получает задание от сервера, запускает ffmpeg/HandBrake CLI и реально перекодирует файл. Node можно поднять внутри контейнера сервера (internalNode: true) или отдельно — хоть на десятке разных серверов, каждый со своим лимитом воркеров.

Именно это разделение и определяет расчёт памяти: Server сам по себе лёгкий, а основной бюджет RAM уходит на количество и тип воркеров на Node. Если вы гоняете один VPS с internal node и парой воркеров — считаете всё в одном месте. Если строите ферму из нескольких GPU-серверов — Server можно держать на минимальной машине, а память закладывать туда, где реально идёт транскодирование.

Раньше Tdarr требовал отдельно поднятый MongoDB для хранения задач и статусов — на маленьких библиотеках это добавляло лишние 200-400 МБ поверх самого сервера. В актуальных версиях используется встроенная файловая база, отдельный MongoDB поднимать не нужно, что немного снижает порог входа по памяти для тех, кто ставит Tdarr в первый раз.

Сколько ест сам Server в простое

Tdarr Server — это Node.js-приложение, и в покое (без активных транскодирований, без сканирования) оно обычно держит 150-350 МБ RAM. Это база: веб-сервер, обработчик API, подключение к встроенной БД.

Дальше добавляется по мере роста библиотеки:

• Размер индекса библиотеки — Tdarr хранит в базе метаданные по каждому просканированному файлу (путь, кодек, битрейт, статус обработки, история). На библиотеке в несколько тысяч файлов индекс некритичен, но на 50 000+ файлов (актуально для больших коллекций сериалов и архивов) память под кеш базы может стабильно держаться в районе 500 МБ-1 ГБ даже без единого активного воркера.
• Сканирование новых файлов — при первом добавлении большой библиотеки или после массового импорта Tdarr параллельно запускает ffprobe по файлам для сбора метаданных. Число параллельных сканирующих потоков задаётся отдельно от воркеров транскодирования (в настройках — Scan Workers), и каждый такой поток кратковременно добавляет по 50-150 МБ, пока идёт разбор контейнера. После завершения сканирования память откатывается.
• Health-check очередь — если включена проверка целостности файлов (health checks через ffmpeg), это отдельная очередь со своими воркерами, которая тоже запускает ffmpeg-процессы, но обычно легче полноценного транскодирования, потому что часто ограничивается разбором потока без полного перекодирования на диск.

Итого простой Server с библиотекой среднего размера (5000-15000 файлов) — это 400-800 МБ. Это фундамент, на который накладывается реальная работа воркеров.

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

Здесь и решается основной вопрос по RAM. Каждый воркер, который вы выставили в настройках ноды (Number of CPU/GPU Workers), при получении задачи запускает собственный процесс ffmpeg с полным набором фильтров и буферов. Ориентировочное потребление на один воркер в зависимости от того, что происходит с видео:

Цифры ориентировочные — сильно зависят от конкретного контента (битрейт исходника, набор фильтров в плагине Tdarr, размер GOP) и от того, CPU это или GPU-воркер. Считайте их отправной точкой для расчёта, а не гарантией.

Практическая формула:

RAM = база Server (0.5-0.8 ГБ)
    + (число CPU-воркеров × 0.3-0.9 ГБ)
    + (число GPU-воркеров × 0.2-0.5 ГБ)
    + запас ОС и файлового кеша (1-2 ГБ)

Ключевой момент, который часто упускают: каждый воркер — это отдельный процесс с собственной памятью, и они не делят буферы между собой. Если вы поставили 4 CPU-воркера, чтобы быстрее прогнать очередь на многоядерном сервере, память нужно закладывать на все 4 параллельных ffmpeg сразу, а не на один типичный.

CPU против GPU-воркеров — разница в памяти и в подходе

Аппаратное перекодирование через NVENC (Nvidia) или QuickSync (Intel) обычно легче по памяти на один воркер, чем программный libx264/libx265, потому что часть буферизации кадров уходит на GPU или видеоядро вместо системной RAM. Но у GPU-транскодирования есть свой потолок — большинство потребительских видеокарт Nvidia ограничивают число одновременных NVENC-сессий на уровне драйвера (актуальные цифры лимита стоит сверять с текущей политикой Nvidia для конкретной серии карт), так что просто накидать побольше GPU-воркеров не всегда получится — упрётесь не в память, а в лимит сессий.

Отдельно стоит тонмаппинг HDR → SDR — если библиотека содержит HDR-контент (4K UHD Blu-ray рипы), а часть клиентов не поддерживает HDR-вывод, Tdarr-плагины гоняют это через фильтры вроде zscale=t=linear,tonemap=hable,zscale=t=bt709. Эти фильтры работают в линейном цветовом пространстве и держат в памяти больше промежуточных буферов кадров, чем обычная смена кодека — именно поэтому в таблице выше HDR-тонмаппинг заметно тяжелее. На CPU это особенно чувствительно; часть тонмаппинг-цепочек можно частично разгрузить на GPU, но с ограничениями по доступным фильтрам на конкретном железе.

Если строите сервер именно под GPU-транскодирование, стоит сразу понимать общие принципы проброса видеокарты в виртуализацию — разобрано в статье основы GPU passthrough.

Распределённая ферма нод — когда одна машина не единственный вариант

Ключевая особенность Tdarr, которая отличает его от обычного медиасервера с точки зрения планирования железа — не обязательно тащить всё на одну мощную машину. Можно поднять Server на скромном VPS, который просто раздаёт задачи, а Node-воркеры развернуть на нескольких отдельных серверах — например, один с GPU под NVENC-очередь, второй с многоядерным CPU под тяжёлый HDR-тонмаппинг. Каждая нода подключается к серверу по сети (задаётся через переменные окружения при старте контейнера):

# docker-compose.yml — пример ноды, подключаемой к внешнему Server
services:
  tdarr-node:
    image: haveagitgat/tdarr_node:latest
    restart: unless-stopped
    environment:
      - nodeID=worker-gpu-01
      - serverIP=10.0.0.5
      - serverPort=8266
      - inContainer=true
    volumes:
      - ./configs:/app/configs
      - /mnt/media:/media
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

Такая схема выгодна именно по памяти: вместо одного сервера на 32 ГБ под все воркеры сразу можно взять два-три сервера поменьше, каждый под свой тип нагрузки, и масштабировать по мере роста очереди — добавили новую ноду, когда старая перестала успевать. Для GPU-веток разумно смотреть в сторону отдельных серверов с видеокартой под инференс/транскодирование — конфигурации разобраны в статье GPU-сервер в США для инференса, принципы подбора там частично пересекаются с задачами транскодирования.

Готовые конфигурации под разные размеры очереди

Эти цифры — под сам Tdarr (Server + Node на одной машине). Если на том же сервере крутится ещё *arr-стек (Sonarr/Radarr для автоматического пополнения библиотеки), медиасервер вроде Jellyfin для просмотра результата или торрент-клиент — закладывайте отдельно ещё 1-3 ГБ под эту связку, Tdarr с ними память не делит.

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

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