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

MAATRIX

PhotoPrism в режиме простоя укладывается в полгигабайта — но стоит запустить первую индексацию архива на 30 тысяч фото, и контейнер вылетает по OOM, а сервер уходит в своп. Разница между «работает» и «падает» здесь не в объёме фотоархива на диске, а в том, что происходит в момент импорта: TensorFlow строит теги, MariaDB пишет индекс, воркеры генерируют превью — и всё это одновременно. Ниже — из чего складывается память PhotoPrism, сколько закладывать под конкретный размер архива и как урезать аппетит, если сервер маленький.

Из чего складывается память PhotoPrism

PhotoPrism — это не один процесс, а связка из нескольких компонентов, и почти все жалобы на нехватку RAM объясняются тем, что считают только первый:

• PhotoPrism (Go-бинарник) — сам веб-сервер и API. В покое, без активных задач, занимает 150–300 МБ.
• Индексатор (photoprism index) — читает файлы, извлекает EXIF, строит превью через libvips/ffmpeg. Каждый параллельный воркер — это отдельный поток декодирования, и на RAW-файлах или 4K-видео каждый такой поток может держать десятки-сотни мегабайт.
• TensorFlow-модель распознавания — здесь и живёт «ИИ-тегирование», ради которого PhotoPrism обычно и ставят. Модель классификации сцен и объектов загружается в память целиком при первом обращении и остаётся там же до перезапуска процесса. Отдельно — модель распознавания лиц (face recognition), она включается по умолчанию и добавляет свой слой поверх.
• MariaDB — хранит метаданные, теги, альбомы, миниатюры-индекс. У PhotoPrism есть встроенный SQLite-режим для маленьких архивов, но production-конфиг почти всегда идёт с внешней MariaDB, и это отдельный процесс со своим innodb_buffer_pool_size.
• Кеш миниатюр на диске — не ест RAM напрямую, но генерация каждого нового размера превью — это операция в памяти перед записью на диск.

Ключевой момент: перечисленное выше не работает по очереди, оно работает параллельно. Индексация 10 тысяч файлов с включённым распознаванием лиц — это одновременно живой TensorFlow, десяток воркеров декодирования и MariaDB, принимающая поток INSERT'ов. Именно сумма пиков, а не сумма «состояний покоя», определяет минимальный объём RAM на сервере.

Индексация — вот где сервер реально проседает

В режиме «сайт просто отдаёт фото по ссылкам» PhotoPrism почти невесом. Проблема начинается в момент docker compose up с первым импортом, и она предсказуема: чем больше файлов ожидает обработки, тем выше держится память, пока очередь не опустеет.

Что конкретно грузит систему при первичной индексации:

1. Декодирование RAW. Файлы с камер (.CR2, .NEF, .ARW) декодируются через darktable-cli или встроенный конвертер — каждый такой процесс на время конвертации может занимать 300–600 МБ, и при нескольких параллельных воркерах это складывается.
2. ИИ-классификация. Каждое новое фото проходит через TensorFlow-модель для генерации тегов («пляж», «собака», «закат») и через отдельную модель для лиц, если она включена. Сама модель уже в памяти, но пакетная обработка сотен файлов подряд создаёт устойчивую нагрузку, а не всплеск на секунду.
3. Генерация превью нескольких размеров. PhotoPrism по умолчанию создаёт несколько разрешений миниатюр под разные места в интерфейсе — это происходит для каждого файла при первом обращении.
4. Запись метаданных в MariaDB. Поток вставок и обновлений индекса, который тем длиннее, чем больше в фото EXIF, GPS-меток и распознанных объектов.

Практический вывод: планируйте RAM не по просмотру готовой галереи, а по тому, сколько нужно, чтобы пережить импорт всего архива целиком. Сервер, купленный впритык под «покой», первая же массовая загрузка фото с телефона или NAS уронит.

Сколько RAM закладывать по размеру архива

Ориентировочные цифры — для связки PhotoPrism + MariaDB на Ubuntu 24.04 в Docker, с включённым распознаванием лиц и тегированием (профиль классификации по умолчанию). У вас будет иначе в зависимости от доли RAW-файлов, среднего разрешения и числа параллельных воркеров — это прикидка для планирования конфигурации, а не гарантированный потолок.

Отдельно про видео: если в архиве много клипов с телефона, добавляйте запас — транскодирование через ffmpeg для просмотра в браузере (когда исходный кодек не поддерживается напрямую) само по себе просит несколько сотен мегабайт на один активный стрим.

Диск считайте отдельно: закладывайте 15–25% сверху объёма исходных файлов на кеш превью и sidecar-файлы (.yml с распознанными данными, если включено их сохранение на диск).

Рабочий docker-compose с лимитами памяти

Конфиг под архив среднего размера (20–50 тысяч фото) с явными лимитами на оба контейнера — чтобы при скачке нагрузки PhotoPrism получил OOM внутри своего лимита, а не уронил вместе с собой всю систему через системный OOM-killer:

services:
  photoprism:
    image: photoprism/photoprism:latest
    restart: unless-stopped
    depends_on:
      - mariadb
    ports:
      - "2342:2342"
    environment:
      PHOTOPRISM_ADMIN_PASSWORD: "смените-меня"
      PHOTOPRISM_DATABASE_DRIVER: "mysql"
      PHOTOPRISM_DATABASE_SERVER: "mariadb:3306"
      PHOTOPRISM_DATABASE_NAME: "photoprism"
      PHOTOPRISM_DATABASE_USER: "photoprism"
      PHOTOPRISM_DATABASE_PASSWORD: "смените-меня-тоже"
      PHOTOPRISM_WORKERS: "2"
      PHOTOPRISM_DISABLE_FACES: "false"
      PHOTOPRISM_DISABLE_TENSORFLOW: "false"
      PHOTOPRISM_SIDECAR_YAML: "true"
    volumes:
      - "./originals:/photoprism/originals"
      - "./storage:/photoprism/storage"
    deploy:
      resources:
        limits:
          memory: 3g
        reservations:
          memory: 1g

  mariadb:
    image: mariadb:11
    restart: unless-stopped
    command: >
      mariadbd
      --innodb-buffer-pool-size=512M
      --transaction-isolation=READ-COMMITTED
      --max-connections=64
    environment:
      MARIADB_AUTO_UPGRADE: "1"
      MARIADB_DATABASE: "photoprism"
      MARIADB_USER: "photoprism"
      MARIADB_PASSWORD: "смените-меня-тоже"
      MARIADB_ROOT_PASSWORD: "смените-меня-снова"
    volumes:
      - "./database:/var/lib/mysql"
    deploy:
      resources:
        limits:
          memory: 1g

PHOTOPRISM_WORKERS — главная ручка под индексацию: число параллельных потоков обработки файлов. Значение по умолчанию зависит от числа ядер CPU, но на маленьком сервере (2 vCPU) лучше явно поставить 1–2, иначе воркеры конкурируют не только за CPU, но и за память под декодирование. innodb_buffer_pool_size для MariaDB держите в пределах 25–40% от лимита памяти самого контейнера базы — ставить его равным всему лимиту не стоит, серверу нужна память ещё и на соединения, сортировки и временные таблицы.

Как снизить потребление RAM без потери функциональности

Если сервер небольшой, а тегирование по ИИ — как раз то, ради чего затевался переезд с облачных фотосервисов, полностью отключать TensorFlow не хочется. Есть более точечные способы уменьшить пик:

• Ограничить число воркеров. PHOTOPRISM_WORKERS=1 на слабом сервере — самый быстрый способ сбить пиковое потребление RAM ценой более долгой индексации. Для фонового процесса это разумный компромисс.
• Индексировать порциями. Вместо того чтобы залить сразу 100 тысяч файлов, добавляйте архив партиями по несколько тысяч — так пик памяти не растягивается на весь объём сразу.
• Отключить распознавание лиц отдельно от тегирования. PHOTOPRISM_DISABLE_FACES: "true" убирает самую тяжёлую модель, оставляя классификацию сцен и объектов — часто этого достаточно, если поиск по людям не критичен.
• Понизить разрешение превью. PHOTOPRISM_JPEG_SIZE и связанные параметры уменьшают объём работы при генерации миниатюр — актуально при большом числе RAW-файлов.
• Вынести MariaDB буфер под реальный объём базы. Для архива до 20 тысяч фото 256 МБ innodb_buffer_pool_size обычно достаточно — раздутый буфер просто резервирует память, которая пригодилась бы индексатору.
• Добавить своп как страховку, а не основную память. Один-два гигабайта свопа не спасут от постоянной нехватки RAM, но сгладят кратковременный пик при импорте. Подробно про расчёт размера — в статье про правильный размер swap для VPS.

Контролировать реальное потребление удобнее всего через docker stats в отдельном терминале во время индексации — так видно живой RSS каждого контейнера, а не оценку по документации.

PhotoPrism и Immich: разница по памяти

Раз PhotoPrism часто выбирают как альтернативу Immich, стоит понимать, откуда берётся разница в требованиях к серверу — она не в качестве кода, а в архитектуре.

Immich с его CLIP-поиском по смыслу изображения («найди фото с закатом на пляже» текстом, а не только тегом) обычно требовательнее к RAM именно из-за отдельного ML-сервиса и растущего pgvector-индекса. PhotoPrism выигрывает на скромном железе за счёт более простой архитектуры — меньше контейнеров, меньше межпроцессного обмена данными. При 2–4 ГБ RAM PhotoPrism обычно реалистичнее; от 8 ГБ, если важнее качество семантического поиска и мобильный бэкап, разница в удобстве может перевесить требования Immich. Точные цифры зависят от версий обоих проектов — это ориентир для выбора, а не готовый бенчмарк.

Мониторинг и что делать, если памяти не хватает

Сигналы, что серверу тесно, видны заранее, если знать, куда смотреть:

# живое потребление контейнеров
docker stats photoprism_photoprism_1 photoprism_mariadb_1

# был ли OOM-killer в деле
dmesg -T | grep -i "out of memory"

# текущее использование swap
free -h

Если docker stats во время индексации показывает, что контейнер PhotoPrism стабильно подходит к лимиту memory: из compose-файла, а dmesg содержит записи об OOM — это не разовый сбой, а систематическая нехватка ресурса, и временные меры (снижение PHOTOPRISM_WORKERS, увеличение свопа) только оттягивают апгрейд. Про общий подход к диагностике нехватки памяти на сервере — в статье что делать при нехватке RAM. Если проект уже не помещается на текущий тариф, проще сразу взять сервер с запасом — на арендованном железе смена конфигурации занимает минуты, без переноса данных вручную между машинами.

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