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

MAATRIX

DokuWiki — редкий случай в мире вики-движков: никакой MySQL, никакого PostgreSQL, страницы лежат прямо на диске обычными текстовыми файлами. Это меняет весь разговор про память — вместо «сколько нужно на PHP плюс сколько на буфер БД» считать приходится только одну часть уравнения. Разберём, из чего реально складывается расход RAM у DokuWiki, сколько закладывать под личную вики и под вики отдела, и почему на слабом VPS этот движок часто оказывается единственным разумным выбором среди вики-систем.

Из чего складывается память DokuWiki: файлы вместо базы данных

Архитектура DokuWiki устроена проще, чем у большинства конкурентов. Страница — это файл data/pages/namespace/page.txt в синтаксисе DokuWiki, история версий — копии в data/attic, вложения — в data/media. Никакого демона БД, который держит буферы, соединения и кэш запросов в памяти постоянно.

Память ест только то, что реально работает при запросе:

• Веб-сервер (nginx) — принимает запрос, отдаёт статику напрямую с диска, всё остальное передаёт в PHP-FPM. 10–20 МБ базового расхода.
• PHP-FPM — каждый воркер парсит синтаксис DokuWiki и рендерит страницу в HTML. Именно число одновременных воркеров определяет пиковый расход, а не общий трафик за день.
• OPcache — кэш скомпилированного байткода PHP, общий для всех воркеров, разумно 32–64 МБ; без него каждый запрос заново компилирует довольно объёмный код движка, и расход по CPU и памяти на воркер ощутимо выше.

Специфика DokuWiki: движок парсит вики-синтаксис в HTML при каждом рендере страницы, но результат кэширует в data/cache — второй запрос той же неизменённой страницы обходится дешевле по CPU. На расход RAM это влияет скорее косвенно, через ОС: файлы кэша и рендеренные страницы охотно оседают в файловом кэше ядра, если свободная память есть, но это не обязательный расход, а бонус от избытка памяти, а не требование к минимуму.

Единственный процесс, который может дать заметный всплеск памяти — переиндексация полнотекстового поиска (bin/indexer.php). В обычном режиме DokuWiki индексирует страницы лениво, по одной, сразу после сохранения — заметной нагрузки это не создаёт. Полная переиндексация всей вики нужна редко (миграция, смена структуры) и на вики с несколькими тысячами страниц стоит закладывать временный запас памяти сверх обычного рабочего минимума.

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

Ниже — инженерный ориентир, не измеренный бенчмарк: реальные цифры сдвинутся в зависимости от версии PHP, включённого OPcache, числа установленных плагинов и того, что ещё крутится на том же сервере.

Разница с БД-движками вроде MediaWiki, Wiki.js или BookStack ощутима именно на нижней границе: там MySQL или PostgreSQL добавляют свой базовый оверхед (буферы, фоновые процессы) поверх PHP или Node, и работающая связка редко укладывается в 512 МБ даже на пустой базе. У DokuWiki этого оверхеда просто нет — если хочется сравнить подход с БД на практике, у нас разобрана установка Outline Wiki на VPS, где память в основном уходит именно на PostgreSQL и Redis, а не на само приложение. Общий подход к тому, сколько закладывать поверх расчётного минимума, — в статье сколько оперативной памяти закладывать с запасом.

Установка: LEMP без единой строчки про MySQL

Ставим DokuWiki на Ubuntu 24.04 без пакета БД — он здесь просто не нужен:

apt update
apt install -y nginx php8.3-fpm php8.3-gd php8.3-xml \
  php8.3-mbstring php8.3-zip php8.3-intl php8.3-curl unzip

cd /var/www
wget https://download.dokuwiki.org/src/dokuwiki/dokuwiki-stable.tgz
tar -xzf dokuwiki-stable.tgz
mv dokuwiki-* dokuwiki
chown -R www-data:www-data /var/www/dokuwiki

Конфиг nginx для DokuWiki обязательно должен закрывать служебные каталоги — там лежат сами страницы и конфигурация, и без явного запрета nginx отдаст их как обычные файлы:

server {
    listen 80;
    server_name wiki.example.com;
    root /var/www/dokuwiki;
    index doku.php;

    location ~ /(data|conf|bin|inc|vendor)/ {
        deny all;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }

    location / {
        try_files $uri $uri/ @dokuwiki;
    }

    location @dokuwiki {
        rewrite ^/(.*) /doku.php?id=$1&$args last;
    }
}

Дальше — установщик по адресу wiki.example.com/install.php: он создаёт администратора, базовую структуру data/ и conf/local.php, и всё — вики готова. Никакого шага «создать базу данных и пользователя БД», который есть почти у любого другого движка из категории сайтов.

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

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

Пример pool.d/dokuwiki.conf под сервер с 1 ГБ RAM, где под PHP разумно отвести около 500–600 МБ:

[dokuwiki]
user = www-data
listen = /run/php/php8.3-fpm.sock
pm = dynamic
pm.max_children = 15
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

Формула та же, что и для любого PHP-FPM пула: pm.max_children = доступная_под_php_память_МБ / средний_вес_процесса_МБ. Для DokuWiki эта цифра обычно даёт больше воркеров на тот же объём памяти, чем аналогичный расчёт для движка с БД, — просто потому что сам процесс легче.

В php.ini для этого пула проверьте, что включён OPcache:

opcache.enable=1
opcache.memory_consumption=64
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1

memory_limit для DokuWiki хватает 128M в подавляющем большинстве случаев — исключение составляет полная переиндексация поиска на вики с тысячами страниц или обработка очень крупных вложений через плагины загрузки файлов, там разумно временно поднять лимит для CLI-запуска bin/indexer.php, а не для всего пула.

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

Здесь стоит явно развести рост диска и рост оперативной памяти — у DokuWiki они связаны слабее, чем у движков с БД:

• Растёт диск, не RAM напрямую: число страниц, история версий в data/attic, вложения в data/media, кэш рендера в data/cache. Тысяча страниц с историей правок легко займёт сотни мегабайт на диске, но сама по себе не требует больше памяти — DokuWiki не держит контент в RAM между запросами, каждый рендер читает нужный файл заново.
• Растёт RAM: число одновременных запросов, то есть посетителей и редакторов, работающих прямо сейчас. Просмотр страницы — это одна операция чтения файла и один PHP-воркер на короткое время; открытая в браузере вкладка память на сервере не держит. Поэтому большая вики с редкими заходами легче для RAM, чем маленькая с активным одновременным редактированием командой.
• Полнотекстовый поиск через data/index растёт с числом страниц линейно, но это индекс на диске, а не структура в памяти — DokuWiki читает его частями по запросу, а не загружает целиком.

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

Бэкап и перенос: главное преимущество плоских файлов

Раз данные DokuWiki — это просто файлы, бэкап сводится к копированию каталога, без дампа базы и без риска несогласованного снепшота на живой БД:

tar -czf dokuwiki-backup-$(date +%F).tar.gz \
  --exclude='data/cache' --exclude='data/tmp' \
  /var/www/dokuwiki/data /var/www/dokuwiki/conf

Каталоги data/cache и data/tmp в бэкап включать не нужно — это восстановимый мусор, который только раздувает архив. Для регулярного бэкапа с ротацией и выгрузкой во внешнее хранилище удобно завести rclone с расписанием — как это настроить, разобрано в статье бэкап и восстановление через rclone, подход применим к каталогу data/ DokuWiki напрямую.

Тот же плюс работает и при переносе на другой сервер: rsync -a data/ conf/ на новую машину с тем же дистрибутивом DokuWiki — и вики поднята, без экспорта-импорта дампа и без риска потерять кодировку или коллацию таблиц при переезде между версиями MySQL. Многие также держат data/pages под git — история коммитов дублирует встроенный attic и даёт возможность откатить конкретную правку через git log, если внутренней истории версий недостаточно.

Несколько вики на одном сервере

Раз DokuWiki не тянет за собой отдельный процесс БД, размещение нескольких независимых вики на одном VPS обходится заметно дешевле по памяти, чем то же самое с движками на MySQL — там каждый инстанс либо делит одну БД (и тогда усложняется изоляция), либо поднимает отдельный процесс сервера БД на каждый сайт.

С DokuWiki обычная схема — общий пул PHP-FPM с несколькими location-блоками в nginx на разные root, каждая вики в своём каталоге /var/www/wiki-clientA, /var/www/wiki-clientB и так далее. Память масштабируется почти линейно по числу активных запросов, а не по числу вики как таковых — пустая вики без посетителей практически ничего не стоит, в отличие от простаивающего процесса MySQL, который держит буферы независимо от нагрузки. Если на сервере уже крутится несколько сайтов разных типов, общий расчёт ресурсов под такую конфигурацию разобран в статье VPS для хостинга нескольких сайтов.

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