Сколько RAM нужно для Trilium Notes

MAATRIX

Trilium Notes — одна из немногих self-hosted систем заметок, которая честно тянет роль личной базы знаний на десятки тысяч записей: дерево заметок, атрибуты, шаблоны, скрипты на JavaScript прямо внутри заметок. Но когда доходит до выбора сервера, документация проекта отвечает расплывчато — "работает даже на Raspberry Pi". Это правда, но не даёт понимания, сколько памяти заложить, если вы планируете держать там 20 тысяч заметок с картинками и синхронизировать три устройства. Разберём по частям, откуда берётся расход RAM и какие цифры закладывать в разных сценариях.

Как устроен Trilium изнутри

Trilium — это Node.js-приложение с SQLite в качестве хранилища. Есть два режима: desktop-клиент на Electron (для локального использования на одной машине) и server-режим — обычный Node.js-процесс, который слушает HTTP-порт и отдаёт веб-интерфейс в браузер. Для домашней базы знаний, доступной с телефона и ноутбука, нужен именно server-режим — он и держит постоянный процесс на VPS.

Ключевые компоненты, которые едят память:

• Node.js runtime — сам движок V8 с базовым набором модулей Express.
• SQLite через better-sqlite3 — база лежит одним файлом, но активно кешируется в память при чтении дерева заметок.
• CKEditor 5 — рендерится в браузере пользователя, на сервер почти не влияет, но полнотекстовая индексация содержимого заметок для поиска — процесс серверный.
• Ревизии заметок — при каждом сохранении Trilium может создавать снапшот старой версии, это разрастающиеся данные в той же SQLite.
• Вложения — картинки, PDF, файлы; Trilium умеет генерировать превью изображений на сервере, что кратковременно поднимает потребление RAM.

Ничего экзотического, но именно комбинация "Node.js + SQLite + генерация превью + синхронизация нескольких клиентов" определяет минимальный порог памяти, а не сам факт "это просто заметки".

Сколько RAM нужно по факту: ориентиры

Точных бенчмарков от разработчиков Trilium (включая форк TriliumNext) немного, а нагрузка сильно зависит от того, сколько заметок, вложений и сколько человек одновременно синхронизируются. Ниже — ориентировочные пороги, собранные из практики эксплуатации похожих Node.js + SQLite сервисов; на вашей инсталляции цифры могут отличаться в ту или иную сторону, особенно если вы держите десятки тысяч заметок с большими вложениями.

Важная оговорка: сам Node.js-процесс Trilium в состоянии покоя редко ест больше 150–250 МБ. Остальное — это запас на пики: полная реиндексация поиска после массового импорта, синхронизация нескольких клиентов подряд, генерация превью для пачки загруженных фотографий. Если взять минимум "впритык", сервис не упадёт в обычный день, но захлебнётся ровно в момент, когда вы решите одним махом импортировать архив старых заметок — а это худший момент для падения сервиса.

Что реально нагружает память

Если хотите понимать, куда уходит RAM, а не просто верить таблице — вот конкретные источники расхода:

• Полнотекстовый поиск. Trilium индексирует содержимое заметок для быстрого поиска по всей базе. На большом объёме текста индекс и его перестроение при импорте — заметный кратковременный скачок потребления.
• Ревизии (note revisions). По умолчанию Trilium хранит историю версий заметки. На активно редактируемой базе это тысячи дополнительных записей в SQLite, которые увеличивают размер файла базы и время его кеширования в память при чтении.
• Вложения и превью изображений. Каждая загруженная картинка при определённых операциях (например, изменение размера для отображения) требует буфера в памяти на время обработки — это не постоянный расход, но пиковый.
• Синхронизация нескольких клиентов. Каждое подключённое устройство (desktop-клиент, браузерная вкладка, мобильный клиент через веб) держит открытое соединение и участвует в sync-протоколе. Три-пять устройств на личном сервере — это не проблема, но десятки одновременных клиентов на командной инсталляции уже стоит закладывать в расчёт.
• Reverse proxy и TLS. Если вы, как обычно рекомендуется, ставите Trilium за nginx или Caddy для HTTPS — это ещё 20–50 МБ поверх самого приложения.

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

Практичнее всего разворачивать Trilium через Docker — так проще следить за потреблением ресурсов и не тащить лишние зависимости на хост. Пример docker-compose.yml для личной базы знаний с явным лимитом памяти:

services:
  trilium:
    image: triliumnext/trilium:latest
    container_name: trilium
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    environment:
      - TRILIUM_DATA_DIR=/home/node/trilium-data
    volumes:
      - ./trilium-data:/home/node/trilium-data
    deploy:
      resources:
        limits:
          memory: 1g
        reservations:
          memory: 256m

Порт намеренно привязан к 127.0.0.1 — наружу сервис отдаётся через reverse proxy с TLS, а не напрямую. Минимальный конфиг Caddy для этого:

notes.example.com {
    reverse_proxy 127.0.0.1:8080
}

Лимит memory: 1g в примере — это защита от аномалий (утечка после длительного аптайма, зависший импорт), а не рекомендуемый минимум для сервера в целом: с учётом ОС, бэкапов и reverse proxy реальный сервер должен иметь запас сверху, а не ровно 1 ГБ. Для личного использования достаточно VPS с 1–2 ГБ RAM в целом, где лимит контейнера — лишь часть картины.

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

Перед тем как переезжать на тариф побольше, полезно понять, действительно ли не хватает RAM или процесс просто раздулся из-за старых ревизий и невыгруженных вложений.

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

docker stats trilium --no-stream

Если видите, что resident memory стабильно близка к лимиту даже в состоянии покоя (без активного использования веб-интерфейса) — это повод почистить историю ревизий заметок через настройки Trilium (там есть управление сроком хранения ревизий) или пересмотреть объём хранимых вложений.

Если памяти не хватает системно (частые OOM-килы контейнера в docker logs или в dmesg), варианты по приоритету:

1. Добавить swap на VPS (2 ГБ swap-файла спасают от жёсткого падения при разовых пиках, но не решают проблему постоянной нехватки — производительность на swap заметно хуже).
2. Проверить, не сам ли лимит deploy.resources.limits.memory в docker-compose стал причиной килла — если контейнеру физически не хватает выделенных рамок, ослабьте лимит.
3. Перейти на тариф с большим объёмом RAM — если нагрузка объективно выросла (база разрослась, добавились пользователи), это единственное устойчивое решение.

Как выбрать сервер под свой сценарий

Для личной базы знаний без претензий на нагрузку хватает младшего тарифа VPS — здесь важнее не запас по RAM, а стабильный аптайм и SSD-диск, потому что SQLite чувствителен к скорости диска при частой записи (каждое сохранение заметки — это транзакция). Если вы уже сравнивали похожие self-hosted альтернативы вроде BookStack или Outline Wiki, заметите общий паттерн: небольшие Node.js/PHP-сервисы на SQLite или лёгкой БД одинаково хорошо чувствуют себя на 1–2 ГБ RAM, пока база не разрастается до десятков тысяч записей.

Для командной инсталляции с несколькими одновременными пользователями и активной загрузкой вложений закладывайте минимум 2 ГБ RAM и 2 vCPU — резерв нужен не столько под сам Trilium, сколько под операции резервного копирования и генерацию превью при массовой загрузке файлов. Если параллельно с Trilium на том же сервере крутится ещё что-то (например, DokuWiki для публичной документации или Wiki.js для другой части команды), считайте память для каждого сервиса отдельно и суммируйте — общего "магического" запаса на все сервисы разом не существует.

Для локации имеет смысл смотреть в сторону сервера ближе к основной команде: если пишете заметки из России, а сервер стоит в Европе или США, задержка в 100–150 мс на каждое сохранение почти не ощущается в интерфейсе Trilium (сохранение асинхронное), так что локацию можно выбирать по другим критериям — цене, юрисдикции, удобству оплаты. Из России это чаще всего означает оплату картой или криптовалютой напрямую, без посредников и конвертации через третьи сервисы.

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