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

MAATRIX

BookStack — это не движок с претензией на энтерпрайз, а простая база знаний: полка → книга → глава → страница, WYSIWYG-редактор без сюрпризов, поиск, который просто работает. Именно поэтому вопрос про RAM возникает почти сразу — документация проекта скупа на цифры, а гадать между тарифом на 1 ГБ и 4 ГБ не хочется. Разберём, из чего на самом деле складывается потребление памяти у связки PHP-FPM + MySQL/MariaDB, которая и есть BookStack, и на что закладываться в реальных сценариях: от личной вики на 50 страниц до базы знаний отдела на несколько сотен пользователей.

Что внутри BookStack и почему это важно для памяти

BookStack написан на PHP (фреймворк Laravel) и требует MySQL или MariaDB — это не блог на статике и не Node-приложение, а классическое веб-приложение с рендерингом на сервере при каждом запросе страницы. Три компонента формируют базовый расход RAM:

• Веб-сервер (nginx или Apache) — принимает запросы, отдаёт статику, проксирует в PHP-FPM. Сам по себе лёгкий, 10–20 МБ.
• PHP-FPM — пул воркеров, каждый рендерит одну страницу за раз. Именно число одновременных воркеров, а не общий трафик, определяет расход памяти.
• MySQL/MariaDB — хранит контент, ревизии страниц, права доступа и полнотекстовый индекс поиска. У БД свой аппетит через innodb_buffer_pool_size.

Важная деталь: поиск в BookStack встроенный, на MySQL FULLTEXT-индексах — отдельного Elasticsearch или Meilisearch не нужно, в отличие от многих других вики-движков. Это делает BookStack заметно легче конкурентов вроде Wiki.js или Confluence по базовому потреблению памяти, но не освобождает от здравого расчёта под БД.

Редактор (TinyMCE) работает в браузере пользователя — на сервер он памяти не добавляет, только увеличивает объём POST-запроса при сохранении страницы с картинками.

Сколько закладывать: ориентир по сценариям

Ниже — не измеренные бенчмарки, а инженерный ориентир исходя из архитектуры (число воркеров PHP-FPM × средний вес процесса + буфер MySQL + ОС). У вас цифры сдвинутся в зависимости от версии PHP, включённого OPcache и объёма контента.

Если сомневаетесь между соседними уровнями — берите больший: разница в стоимости между 2 и 4 ГБ на VPS обычно меньше, чем цена простоя из-за OOM-киллера в разгар рабочего дня. Общий подход к запасу по памяти на любом сервисе разобран в статье сколько оперативной памяти закладывать с запасом.

Docker vs классическая установка: разница в памяти

BookStack можно поднять двумя путями, и они по-разному ведут себя с точки зрения RAM.

Docker Compose — самый быстрый старт, официально документированная схема с образами linuxserver/bookstack и linuxserver/mariadb:

version: "3"
services:
  bookstack:
    image: lscr.io/linuxserver/bookstack:latest
    environment:
      - PUID=1000
      - PGID=1000
      - APP_URL=https://wiki.example.com
      - DB_HOST=bookstack_db
      - DB_USER=bookstack
      - DB_PASS=changeme
      - DB_DATABASE=bookstackapp
    volumes:
      - ./config:/config
    ports:
      - 6875:80
    restart: unless-stopped
    depends_on:
      - bookstack_db

  bookstack_db:
    image: lscr.io/linuxserver/mariadb:latest
    environment:
      - PUID=1000
      - PGID=1000
      - MYSQL_ROOT_PASSWORD=changemeroot
      - TZ=Europe/Moscow
      - MYSQL_DATABASE=bookstackapp
      - MYSQL_USER=bookstack
      - MYSQL_PASSWORD=changeme
    volumes:
      - ./db:/config
    restart: unless-stopped

Два контейнера — это два независимых процесса MySQL и PHP-FPM, каждый со своим базовым оверхедом. На маленьких серверах (1 ГБ) это ощутимо: Docker плюс два полноценных контейнера съедают заметный кусок памяти ещё до первого запроса пользователя.

Классическая установка на LEMP (nginx + PHP-FPM + MySQL напрямую на хосте) экономичнее на слабых машинах — нет накладных расходов контейнеризации, легче тонко настроить pm.max_children и innodb_buffer_pool_size под конкретный объём RAM:

apt install -y nginx mariadb-server php8.3-fpm php8.3-mysql \
  php8.3-mbstring php8.3-xml php8.3-curl php8.3-zip php8.3-gd \
  php8.3-tokenizer php8.3-bcmath php8.3-ldap composer git

git clone https://github.com/BookStackApp/BookStack.git --branch release --single-branch /var/www/bookstack
cd /var/www/bookstack
composer install --no-dev --optimize-autoloader
cp .env.example .env
php artisan key:generate
php artisan migrate --force

На сервере с 1–2 ГБ RAM разница между Docker и классической установкой ощущается сразу; на 4 ГБ и выше она перестаёт быть значимой — там уже с запасом хватает на любую схему.

Настройка PHP-FPM под доступную память

Главный рычаг для памяти на стороне BookStack — число процессов PHP-FPM. Каждый воркер держит в памяти интерпретатор PHP плюс загруженный код Laravel — ориентировочно 40–70 МБ на процесс с включённым OPcache (без OPcache заметно больше, включайте его всегда).

Пример pool.d/bookstack.conf под сервер 2 ГБ, где под PHP разумно выделить около 700–800 МБ (остальное — MySQL, nginx, ОС):

[bookstack]
user = www-data
pm = dynamic
pm.max_children = 12
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

Формула грубая, но рабочая: pm.max_children = доступная_под_php_память_МБ / средний_вес_процесса_МБ. Если сервер регулярно упирается в лимит воркеров под нагрузкой нескольких одновременных редакторов — это сигнал не гнаться за большим max_children на тесной машине, а поднять RAM, иначе воркеры начнут вытеснять друг друга в своп и BookStack станет отвечать медленнее, а не быстрее.

В php.ini для FPM-пула BookStack хватает разумного memory_limit — 256M с запасом достаточно даже для импорта объёмных страниц с картинками; раздувать его до гигабайта смысла нет, это не спасёт от нехватки RAM на сервере в целом, а лишь отсрочит падение процесса.

MySQL/MariaDB: буфер под реальный размер базы

БД BookStack — не самая большая часть нагрузки, но именно она определяет отзывчивость поиска и списков книг. Ключевой параметр — innodb_buffer_pool_size: если весь рабочий набор данных (таблицы страниц, ревизий, полнотекстовый индекс) помещается в буфер, чтение идёт из памяти, а не с диска.

# /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
innodb_buffer_pool_size = 256M
innodb_buffer_pool_instances = 1
innodb_log_file_size = 64M
tmp_table_size = 32M
max_heap_table_size = 32M

256 МБ буфера с запасом хватает на базу знаний в несколько тысяч страниц с историей ревизий — сама текстовая база у BookStack компактная, основной объём диска съедают приложенные файлы и картинки, которые хранятся отдельно от БД и в буфер пула не попадают. На серверах от 4 ГБ буфер можно смело поднять до 512 МБ – 1 ГБ, если MySQL — единственный тяжёлый сервис на машине; общие принципы такой настройки под ограниченную память разобраны в статье оптимизация MySQL под 1 ГБ RAM — методика применима и к MariaDB под BookStack.

Что растёт со временем и что на это не влияет

Отдельно стоит развести два типа роста, которые часто путают:

• Растёт диск, не RAM: вложенные файлы, изображения в страницах, история ревизий (BookStack хранит полные снимки версий текста при каждом сохранении). Это увеличивает объём БД и папку storage, но не требует больше оперативной памяти напрямую — до тех пор, пока вы не пытаетесь держать весь объём в буфере InnoDB для максимальной скорости.
• Растёт RAM: число одновременных редакторов и читателей. Открытая страница в браузере не держит соединение с сервером — PHP-FPM обрабатывает запрос и освобождает воркер. Поэтому 200 зарегистрированных пользователей, которые заходят по одному в день, легче для памяти, чем 15 человек, редактирующих документацию одновременно в разгар спринта.

Отдельно стоит помнить про резервное копирование: mysqldump на живой базе с активной нагрузкой временно добавляет расход памяти и I/O — на тесных 1 ГБ серверах лучше выносить бэкап на ночное время с низкой активностью или использовать mariadb-backup вместо логического дампа для больших баз.

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

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