Сколько RAM нужно для Collabora Online

MAATRIX

Если вы поднимаете Collabora Online как замену Google Docs внутри своего Nextcloud, первый практический вопрос — не «как установить», а «сколько сервера под это выделить». Документация Collabora даёт цифры «для галочки», а на практике контейнер может упасть по OOM после третьего одновременно открытого файла. Разберём, из чего складывается потребление памяти у CODE (Collabora Online Development Edition) и как посчитать RAM под свою нагрузку, а не под абстрактный «средний случай».

Что такое Collabora Online и почему память здесь не как у обычного сайта

Collabora Online — это серверный движок на базе LibreOffice, который рендерит документы (Writer, Calc, Impress) в браузере и синхронизирует правки в реальном времени через WebSocket. Технически это не веб-приложение в привычном смысле, а headless-версия LibreOffice (форк под именем coolwsd), обёрнутая в Docker-образ collabora/code. Она работает как отдельный сервис и подключается к Nextcloud, ownCloud или ONLYOFFICE-совместимому хранилищу по протоколу WOPI — то есть сама CODE не хранит файлы, а только открывает их по запросу и отдаёт обратно.

Ключевое отличие от типового сайта: память тут расходуется не на обработку HTTP-запросов, а на живые процессы LibreOffice — по сути, на каждый активно редактируемый документ поднимается облегчённый инстанс офисного движка. Это принципиально другая модель нагрузки: она масштабируется не по трафику, а по числу одновременно *открытых на редактирование* документов, и именно эту метрику нужно закладывать в расчёт RAM, а не число посетителей сайта.

Базовое потребление: сколько ест контейнер в простое

Сам по себе контейнер collabora/code в состоянии покоя (запущен, но документы не открыты) занимает по факту немного — процесс coolwsd плюс форкнутый пул воркеров. Ориентировочно на старте стоит закладывать 1–1.5 ГБ RAM просто под живой контейнер с прогретыми шрифтами и словарями, даже без единого открытого файла. Это не жёсткое измеренное число — оно зависит от версии образа и набора установленных языковых пакетов, но как нижняя граница для планирования подходит.

Дальше добавляется цена за каждый открытый документ. У LibreOffice-движка есть накладные расходы на инициализацию сессии редактирования (шрифты, стили, undo-буфер), и это заметно больше, чем открыть вкладку в браузере. Ориентир, с которым стоит закладывать резерв: 150–400 МБ на один активно редактируемый документ, причём тяжёлые Calc-таблицы с формулами и Impress-презентации с картинками съедают заметно больше, чем текстовый Writer-документ на пару страниц. Это тоже прикидка для планирования, а не гарантированное число — на вашем сервере с вашими файлами цифры будут отличаться, проверяйте через docker stats на реальной нагрузке.

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

Ниже — ориентировочная раскладка для планирования сервера. Считаем «одновременный пользователь» как человека, у которого документ реально открыт и он что-то печатает или скроллит прямо сейчас, а не просто залогинен в Nextcloud.

Обратите внимание на строку про Calc: таблицы с активными формулами и большим числом ячеек ощутимо тяжелее текстовых документов, поэтому если у вас бухгалтерия или финансовый отдел держит открытыми Excel-подобные файлы весь день — закладывайте RAM по верхней границе диапазона, а не по нижней.

Установка через Docker Compose с ограничением памяти

Стандартный способ развернуть Collabora — Docker-образ collabora/code. Разумно сразу поставить лимит памяти на уровне Compose, чтобы контейнер не мог захватить всю RAM сервера и не утащил за собой соседние сервисы при всплеске нагрузки:

services:
  collabora:
    image: collabora/code:latest
    restart: unless-stopped
    environment:
      - domain=cloud\\.example\\.com
      - username=admin
      - password=StrongPasswordHere
      - extra_params=--o:ssl.enable=false --o:ssl.termination=true
      - dictionaries=ru_RU en_US
    ports:
      - "9980:9980"
    cap_add:
      - MKNOD
    deploy:
      resources:
        limits:
          memory: 4g
          cpus: "2.0"
        reservations:
          memory: 2g

Параметр domain должен совпадать с адресом вашего Nextcloud (регэксп с экранированными точками), иначе WOPI-запросы будут отклоняться. extra_params с ssl.termination=true уместен, если TLS уже терминируется на реверс-прокси перед контейнером — это частая связка с Nginx или Caddy. Лимит memory: 4g — это потолок для сценария «малая команда» из таблицы выше; под своё число пользователей его нужно пересчитать.

Для более тонкой настройки поведения самого движка (не Docker-лимитов, а внутренних) правится coolwsd.xml внутри контейнера — там есть секция per_document, где можно ограничивать виртуальную память на процесс и число одновременно открытых документов на воркер (limit_load_secs, num_prespawn_children и похожие параметры). Дефолтные значения в разных версиях образа отличаются, поэтому проверяйте актуальный файл конфигурации внутри своего контейнера командой docker exec -it collabora cat /etc/coolwsd/coolwsd.xml, прежде чем что-то менять руками.

Collabora + Nextcloud на одном сервере: как считать RAM суммарно

Частая ошибка — посчитать RAM под Collabora отдельно, под Nextcloud отдельно, и не учесть, что оба сервиса и MySQL/PostgreSQL под ними будут делить одну и ту же физическую память. Если вы разворачиваете связку на одном VPS, план такой:

• Nextcloud (PHP-FPM + веб-сервер) — от 1 до 2 ГБ на среднюю установку, подробнее в материале про установку Nextcloud на VPS.
• База данных (обычно MariaDB/PostgreSQL) — 1–2 ГБ, больше при активной синхронизации файлов.
• Redis для кэша Nextcloud (если используется) — обычно укладывается в 256–512 МБ.
• Collabora Online — по таблице выше, в зависимости от числа одновременных редакторов.
• Плюс системный резерв ОС и файловый кэш — минимум 1 ГБ сверху, иначе сервер начнёт задыхаться при любом пике.

Итого для связки «Nextcloud + Collabora на 5–10 активных пользователей документов» разумно закладывать сервер от 8 ГБ RAM, а не от 4 — иначе первое же совпадение по времени «кто-то открыл Excel» и «идёт бэкап базы» приведёт к своппингу или OOM-killer. Если нагрузка на документы регулярно выше 15–20 одновременных сессий, Collabora стоит вынести на отдельный VPS и подключать к Nextcloud по внутренней сети — так проще масштабировать каждый компонент независимо и не гадать, кто именно съел память при инциденте. Есть и альтернативный путь — ONLYOFFICE вместо Collabora, у него другая модель потребления ресурсов, и для некоторых сценариев она оказывается легче.

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

Если сервер уже куплен и апгрейдить его пока не хочется, есть рабочие способы ужать аппетит Collabora:

• Ограничить число языковых словарей. Каждый установленный словарь для проверки орфографии подгружается в память при старте воркера. Если команда пишет только на русском и английском, не тащите в образ десяток лишних локалей — используйте dictionaries=ru_RU en_US вместо полного набора.
• Отключить неиспользуемые модули. Если presentations (Impress) в компании никто не открывает через Collabora, а только текстовые документы и таблицы — часть накладных расходов на инициализацию можно снизить настройками WOPI-хоста на стороне Nextcloud (ограничение типов файлов, которые открываются через онлайн-редактор).
• Настроить таймаут закрытия неактивных сессий. У CODE есть параметры автозакрытия документов без активности — если пользователь открыл файл и забыл вкладку открытой на час, воркер продолжает висеть в памяти зря. Уменьшение таймаута идле-сессий освобождает RAM быстрее.
• Не полагаться на swap как на замену RAM. Collabora — процесс с активным CPU и памятью в реальном времени; если движок начинает уходить в своп при редактировании, пользователь почувствует это как зависания курсора и разрывы совместного редактирования, а не как плавное замедление. Про правильный расчёт подкачки — в статье про размер swap для VPS, но воспринимайте своп здесь как страховку на случай всплеска, а не как рабочий инструмент экономии.
• Разнести CODE и базу данных по разным контейнерам с явными лимитами. Без deploy.resources.limits в Compose один процесс LibreOffice-воркера при обработке битого или очень большого файла может утянуть память соседних сервисов вниз вместе с собой.

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

Прежде чем угадывать конфигурацию, посмотрите на реальные цифры. Базовая команда для контейнерного окружения:

docker stats collabora --no-stream

Она покажет текущее потребление RAM и CPU конкретно контейнером Collabora в моменте. Для истории по времени полезнее что-то вроде docker stats в связке с cron-логированием в файл, либо полноценный мониторинг через Prometheus + node-exporter/cAdvisor, если сервер уже используется под несколько сервисов и хочется видеть графики, а не моментальные снимки.

Если видите, что контейнер регулярно упирается в лимит и получает OOMKilled в docker inspect collabora, вариантов два: поднять memory лимит в Compose (если на сервере есть свободная RAM) или физически увеличить объём сервера. Общий подход к диагностике нехватки памяти на VPS — в статье что делать при нехватке RAM: та же логика применима и к контейнеру Collabora, просто единицей измерения выступает не весь сервер, а конкретный сервис.

Отдельно стоит различать два симптома: если падает именно контейнер CODE (в логах dmesg видно Out of memory: Killed process для процесса coolwsd или soffice), это нехватка памяти именно под движок редактирования — помогает лимит выше или меньше одновременных сессий. Если же тормозит вся система целиком, включая SSH-подключение, скорее всего под давлением вся ОС, и здесь без увеличения общего объёма RAM на сервере не обойтись.

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