Сколько RAM нужно для Calibre-Web

MAATRIX

Calibre-Web выглядит как игрушечное приложение — веб-морда для библиотеки книг, ну что там может есть память. И в простое это правда: сам сервис легковесный. Но стоит включить конвертацию форматов «на лету» или подключить полнотекстовый поиск по PDF, и картина меняется — не катастрофически, но достаточно, чтобы виртуалка на 512 МБ начала уходить в своп при каждом открытии книги в непривычном формате. Разберём, из чего складывается расход памяти и какую конфигурацию брать под разные сценарии.

Что вообще делает Calibre-Web и почему это не «то же самое, что Calibre»

Calibre-Web — это Flask-приложение на Python, которое читает базу metadata.db, созданную десктопным Calibre, и отдаёт её содержимое через браузер: обложки, описания, теги, поиск, скачивание файлов, OPDS-фид для читалок (Kobo, PocketBook, приложения вроде KOReader) и опциональный синк с Kindle по e-mail. Сам Calibre-Web конвертацией и редактированием метаданных не занимается — для этого он по желанию дёргает бинарник ebook-convert из полноценного пакета Calibre, если тот установлен внутри контейнера или системы.

Это ключевой момент для расчёта памяти: есть два принципиально разных профиля нагрузки.

• Только чтение библиотеки — отдача уже готовых EPUB/MOBI/PDF файлов, работа с обложками и метаданными. Это тонкий слой поверх SQLite и файловой системы, памяти нужно немного.
• Библиотека с конвертацией — когда читалка просит книгу в формате, которого нет в библиотеке (например, есть только EPUB, а Kindle просит AZW3), Calibre-Web на лету вызывает конвертер. Это уже отдельный процесс со своим потреблением RAM, который может быть заметно тяжелее самого веб-сервера.

Если вы просто раздаёте книги в исходном формате — можно почти не думать о памяти. Если рассчитываете на автоконвертацию под разные читалки — стоит закладывать запас.

Из чего складывается потребление RAM

Сам процесс Calibre-Web. Flask + gunicorn/waitress (в зависимости от образа) в простое держат немного — это обычный питоновский веб-процесс без тяжёлых зависимостей в базовом режиме.

SQLite-база metadata.db. Чем больше книг в библиотеке, тем больше база, но она читается с диска постранично, а не грузится целиком в память. На библиотеке в несколько тысяч книг размер базы обычно от нескольких десятков до сотни-другой мегабайт — заметная часть уходит на файловый кеш ОС (это нормально, страничный кеш не «съедает» память безвозвратно, ядро отдаст её при нехватке).

Генерация и кеш обложек. При первом открытии книги Calibre-Web может генерировать миниатюру обложки — короткий всплеск, не постоянная нагрузка.

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

Полнотекстовый поиск (если включён). Индексация содержимого книг (не только метаданных) — самая тяжёлая опциональная функция после конвертации. Индекс строится по всей библиотеке и держит часть данных в памяти при поиске.

Конвертация ebook-convert. Отдельный процесс на базе движка Calibre, который распаковывает исходный файл, перестраивает структуру и упаковывает в целевой формат. Больше всего памяти отъедают PDF с картинками и книги с версткой — на голых текстовых EPUB конвертация почти незаметна, на сканах в PDF счёт может пойти на сотни мегабайт кратковременно.

Сколько RAM реально нужно: таблица по сценариям

Цифры ниже — ориентир по типичным паттернам использования, а не результат стендового бенчмарка: точные значения зависят от версии образа, размера библиотеки и того, что именно вы читаете. Проверяйте на своей нагрузке через docker stats.

Для одного человека или небольшой семьи с библиотекой без систематической конвертации 1 ГБ RAM закрывает вопрос с запасом — это тот случай, когда переплачивать за 4-8 ГБ смысла нет. Отдельная память нужна не столько под Calibre-Web, сколько про запас на конвертацию и на саму операционную систему с Docker.

Конвертация форматов — главный пожиратель памяти

Если вы храните библиотеку в одном формате (обычно EPUB) и читаете с разных устройств, включённая опция «конвертировать на лету» превращает Calibre-Web из тонкого веб-сервера в сервис, периодически запускающий полновесный конвертер.

Что стоит знать:

• Конвертация PDF тяжелее конвертации EPUB/MOBI на порядок — PDF нужно распарсить как набор страниц с фиксированной вёрсткой и переверстать в текстовый поток, это CPU- и RAM-затратно одновременно.
• Каждый запрос на конвертацию — отдельный короткий процесс. Если несколько человек одновременно скачивают книги в непривычных форматах, всплески могут накладываться друг на друга.
• В официальном образе linuxserver/calibre-web бинарник Calibre для конвертации нужно доустанавливать отдельно (через Install Calibre binary в настройках админки) — без него конвертация просто не работает, и память экономится автоматически.

Практический совет: если конвертация нужна только для Kindle-синка через e-mail, а не для постоянного скачивания в разных форматах, держите её включённой, но не рассчитывайте библиотеку под пиковую параллельную нагрузку — такие запросы редки и не идут пачками.

# фрагмент docker-compose.yml — типичная установка
services:
  calibre-web:
    image: lscr.io/linuxserver/calibre-web:latest
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Moscow
      - DOCKER_MODS=linuxserver/mods:universal-calibre  # добавляет ebook-convert
    volumes:
      - ./config:/config
      - /path/to/library:/books
    ports:
      - 8083:8083
    restart: unless-stopped
    mem_limit: 1g

Мод universal-calibre добавляет в образ полноценный конвертер — без него конвертация недоступна вовсе, и это самый простой способ снизить требования к памяти, если она не нужна.

Как ограничить и проверить память в Docker

Не гадайте на кофейной гуще — поставьте лимит и посмотрите на реальное потребление под своей библиотекой.

# ограничить контейнер сверху (важно и для защиты соседних сервисов на той же машине)
docker update --memory=1g --memory-swap=1g calibre-web

# посмотреть текущее потребление в реальном времени
docker stats calibre-web

# посмотреть пик потребления с момента старта контейнера (Linux cgroups v1/v2)
cat /sys/fs/cgroup/memory.peak 2>/dev/null || cat /sys/fs/cgroup/memory/memory.max_usage_in_bytes

Если контейнер регулярно упирается в лимит при конвертации — это не повод сразу же удваивать память на всём сервере, достаточно поднять лимит именно для сервиса, оставив запас для ОС и остальных контейнеров. Общий подход к распределению памяти между сервисами на одном сервере разобран в статье про лимиты CPU и памяти в Docker.

Полезно сразу настроить swap на 1-2 ГБ даже на VPS с достаточным объёмом RAM — короткие всплески при конвертации PDF с картинками swap сгладит без падения контейнера, а постоянно в своп процесс уходить не будет, если базовой памяти хватает.

Типичные ошибки и что с ними делать

Контейнер падает по OOM при попытке скачать книгу в другом формате. Почти всегда это конвертация PDF на слабой виртуалке без swap. Решение: добавить swap-файл или поднять mem_limit, либо отключить автоконвертацию для тяжёлых форматов и хранить книги сразу в нескольких форматах на диске (место дешевле, чем RAM).

Память растёт со временем и не отдаётся. Проверьте, не включена ли индексация полнотекстового поиска, которая пересчитывается при каждом добавлении книги — на большой библиотеке это может держать процесс дольше ожидаемого. Плюс часть «роста» — это файловый кеш ОС под metadata.db и обложки, он не является утечкой и освобождается по требованию.

Обложки не генерируются или генерируются с задержкой на слабом сервере. Обычно это CPU, а не RAM — генерация миниатюр упирается в процессор при большом количестве добавленных за раз книг. Добавляйте библиотеку порциями, а не разом на 10000+ файлов.

Общий сервер «подвисает», хотя Calibre-Web вроде бы лёгкий. Проверьте соседей — если на том же VPS крутится медиатека или Nextcloud, считать память нужно суммарно. Смотрите разбор сколько RAM нужно Nextcloud или Photoprism, если это ваш случай — и общее руководство что делать при нехватке RAM.

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