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

MAATRIX

Официальная документация Matomo называет скромные цифры — 1 ГБ RAM «достаточно» для старта, и формально это правда: веб-установщик действительно поднимется на минимальной машине. Проблема начинается через месяц-два, когда таблица log_visit набирает десятки тысяч строк, а фоновый archiving по cron внезапно съедает всю доступную память и роняет MySQL по OOM. Разберём, из чего на самом деле складывается память Matomo, где происходит основной расход и как посчитать нужный объём под свой трафик, а не гадать по общим рекомендациям.

Короткий ответ: сколько закладывать по трафику

Ориентиры для связки Nginx + PHP-FPM 8.3 + MariaDB 10.11 на Ubuntu 24.04, archiving через cron раз в час (без браузерного пересчёта отчётов).

Это ориентиры, а не гарантия — на них сильно влияет число подключённых сайтов (idSite), глубина хранения сырых логов и то, сколько кастомных отчётов и сегментов вы считаете. Один сайт с 50 тысячами визитов и без сегментов легче пяти сайтов по 10 тысяч каждый: archiving у Matomo идёт по каждому idSite отдельно, и накладные расходы на переключение контекста растут с числом сайтов быстрее, чем с суммарным трафиком.

Главное из таблицы: сам PHP-процесс Matomo лёгкий, память съедает не он, а archiving поверх базы данных. Это принципиально отличает Matomo от типичного PHP-сайта вроде WordPress, где основной потребитель — параллельные воркеры под живой трафик.

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

У Matomo нет одного «веса» — есть три независимых процесса с разной динамикой.

PHP-FPM для фронтенда и трекера. Каждый визит отправляет запрос на matomo.php — лёгкий скрипт, который пишет строку в log_visit и log_link_visit_action. Воркер под трекинг занимает 20–35 МБ RSS, живёт недолго и не накапливает состояние. Дашборд администратора тяжелее — рендер отчётов доходит до 60–90 МБ на воркер, но это разовые обращения, а не постоянная нагрузка.

Archiving-процесс (core:archive). Вот где на самом деле расходуется память. Это CLI-скрипт, который раз в час агрегирует сырые визиты в предрассчитанные отчёты — без него дашборд пересчитывал бы всё «на лету» при каждом открытии. Archiving одного дня для активного сайта легко занимает 150–400 МБ, а пересчёт месяца или сразу нескольких сайтов подряд — от 500 МБ до 1,5+ ГБ, в зависимости от числа сегментов и плагинов отчётности (Ecommerce, Custom Dimensions, Funnels).

MariaDB/MySQL. Та же логика InnoDB-буфера, что и в любой другой базе: чем больше пул относительно объёма таблиц log_visit/log_link_visit_action/log_conversion, тем меньше чтений уходит на диск при archiving. Разница с обычным сайтом в том, что эти таблицы растут монотонно и без чистки — за год трекинга набегают гигабайты сырых данных, если не настроено удаление старых логов.

SELECT ROUND(SUM(data_length+index_length)/1024/1024) AS mb
FROM information_schema.tables
WHERE table_schema = 'matomo' AND table_name LIKE 'log_%';

Если результат этого запроса заметно превышает innodb_buffer_pool_size, archiving будет идти дольше и требовать больше памяти на каждый прогон — база не удерживает горячие данные в кеше и ходит на диск.

Почему archiving — реальный источник OOM

Типичный сценарий падения: сервер на 2 ГБ спокойно работает месяц с одним небольшим сайтом, потом кто-то подключает второй сайт с историческим импортом или запускает core:archive --force-all-websites --force-all-periods вручную для отчёта за квартал. Archiving пытается пересчитать сразу десятки периодов (день/неделя/месяц/год) по всем сайтам, память растёт с числом периодов в очереди, и в какой-то момент ядро убивает либо сам процесс archiving, либо — что хуже — MariaDB, которая держала открытые соединения под этот же процесс.

Out of memory: Killed process 8842 (php8.3) total-vm:1842332kB, anon-rss:687912kB
Out of memory: Killed process 741 (mariadbd) total-vm:1203448kB, anon-rss:412980kB

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

dmesg -T | grep -iE "killed process|out of memory"
tail -50 /var/log/matomo-archive.log | grep -iE "error|fatal|memory"

Строка PHP Fatal error: Allowed memory size of ... bytes exhausted в логе archiving — прямой сигнал поднять memory_limit для CLI-пула, но перед этим убедитесь, что физической памяти на сервере хватит с запасом, иначе вы просто отодвинете момент падения.

Как измерить реальный расход на своём сервере

Не гадайте по чужим цифрам — расход слишком зависит от числа сайтов, плагинов и сегментов. Замерьте archiving напрямую:

/usr/bin/time -v php8.3 /var/www/matomo/console core:archive \
  --url=https://analytics.example.com > /tmp/archive-test.log 2>&1
grep -E "Maximum resident set size|Elapsed" /tmp/archive-test.log

Maximum resident set size — пиковый расход памяти за прогон archiving, самая честная цифра для планирования. Общее состояние сервера во время прогона удобно смотреть отдельным терминалом:

watch -n2 'free -m; echo; ps --no-headers -o rss,cmd -C php8.3 --sort=-rss | head -5'

Для MariaDB интересен фактический размер данных в памяти против настроенного пула:

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SELECT (SELECT SUM(data_length+index_length) FROM information_schema.tables
  WHERE table_schema='matomo') AS db_bytes;

Если db_bytes заметно больше innodb_buffer_pool_size, это узкое место раньше, чем сама архитектура сервера — расширение диска тут не поможет, нужна память под буфер. Общие принципы разбора free -m и разницы между free и available подробно разобраны в статье про swap на VPS — механика для Matomo та же.

Настройка archiving, MariaDB и PHP-FPM

Главный рычаг — не давать archiving обрабатывать больше, чем сервер способен переварить за один проход.

; config/config.ini.php
[General]
enable_browser_archiving_triggering = 0
time_before_archive_considered_outdated = 3600

Отключение enable_browser_archiving_triggering обязательно уже на старте — иначе первый же посетитель, открывший дашборд с непосчитанными данными, запускает archiving синхронно в рамках HTTP-запроса, и PHP-FPM пул с коротким request_terminate_timeout просто обрывает процесс на середине.

crontab -u www-data -e

5 * * * * /usr/bin/php8.3 /var/www/matomo/console core:archive \
  --concurrent-requests-per-website=1 \
  --url=https://analytics.example.com >> /var/log/matomo-archive.log 2>&1

--concurrent-requests-per-website=1 — ключевой параметр на слабых серверах: по умолчанию Matomo может параллелить archiving нескольких сайтов, и на 2–4 ГБ это верный способ поймать OOM при первом же прогоне после подключения нескольких сайтов разом. На сервере с 8+ ГБ параллелизм, наоборот, ускоряет прогон и его можно поднять до 2–3.

Буферный пул MariaDB считайте по фактическому размеру таблиц log_*, а не по проценту от RAM — то же правило, что и для любого MySQL-проекта, подробнее в статье про оптимизацию MySQL под 1 ГБ RAM:

# /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
innodb_buffer_pool_size = 1024M
innodb_log_file_size = 128M
max_connections = 40
performance_schema = OFF

performance_schema = OFF для MySQL 8.0+ экономит 150–250 МБ — на архивирующей нагрузке эта подсистема почти бесполезна, а память ест постоянно. Для MariaDB она и так выключена по умолчанию.

Пул PHP-FPM под сайт держите отдельно от лимитов archiving:

; /etc/php/8.3/fpm/pool.d/matomo.conf
pm = dynamic
pm.max_children = 6
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
request_terminate_timeout = 300
php_admin_value[memory_limit] = 256M

А для CLI, из-под которого запускается archiving, memory_limit в /etc/php/8.3/cli/php.ini поднимите отдельно — 512M для 4 ГБ сервера, 1024M для 8 ГБ и выше, но не безлимитно: без потолка одна зависшая архивация с утечкой в плагине способна съесть всю память сервера, включая ту, что нужна MariaDB.

Чистка старых данных снижает нагрузку сильнее апгрейда

Прежде чем добавлять память, проверьте, не растут ли таблицы бесконтрольно. Matomo умеет удалять или анонимизировать сырые логи посетителей автоматически — Administration → Privacy → Data Anonymization в интерфейсе, либо сразу в конфиге:

[Deletelogs]
delete_logs_enable = 1
delete_logs_schedule_lowest_interval = 7
delete_logs_older_than = 180

Через полгода-год без такой настройки таблица log_link_visit_action (строка на каждое действие посетителя, а не на визит) обычно становится самой тяжёлой в базе — именно она чаще всего выталкивает буферный пул за пределы разумного. После включения удаления логов освободите место вручную одной командой:

php8.3 /var/www/matomo/console core:purge-old-archive-data --dates=all

Это не заменяет апгрейд сервера при реальном росте трафика, но откладывает его на месяцы — особенно если Matomo стоит на VPS для одного-двух сайтов, а не как централизованная аналитика на десятки проектов.

Какой сервер взять под Matomo

Правило простое: память нужна не под сам сайт, а под пиковый archiving, поэтому считать стоит не средний трафик, а худший день — распродажа, вирусный пост, всплеск от рекламной кампании. Если типичный день даёт 500 визитов, а пиковый — 8000, ориентируйтесь на пиковый, потому что именно его archiving обработает следующим прогоном cron.

Минимум: 1–2 vCPU, 2 ГБ RAM, 25 ГБ NVMe. Один сайт с трафиком до 10 тысяч визитов в месяц, archiving раз в час с --concurrent-requests-per-website=1, буферный пул 512 МБ. Дальше расти по числу подключённых сайтов сюда закладывать не стоит — второй активный сайт на этой конфигурации почти гарантированно приведёт к OOM при первом крупном archiving.

Комфортный вариант: 2–4 vCPU, 4–8 ГБ RAM, 60–120 ГБ NVMe. До 5–10 сайтов, буферный пул 1–2 ГБ под объём log_*-таблиц, параллельный archiving на 2–3 сайта одновременно. Диск с запасом важен отдельно от памяти — сырые логи визитов растут быстрее, чем кажется, если не настроено автоудаление.

Локация — RU, если аудитория и владелец сервера в России: минимальный пинг для трекинг-скрипта на своих сайтах и однозначное соответствие 152-ФЗ для персональных данных посетителей. Для аудитории в Европе логичнее UK — Matomo как раз и ставят вместо Google Analytics ради контроля над юрисдикцией хранения этих данных, так что локация сервера здесь не техническая деталь, а часть смысла всей затеи.

Развернуть саму установку с нуля — от чистой Ubuntu до первого отчёта — можно по шагам из статьи про установку Matomo на VPS; там же разобраны SSL и структура cron-задачи, здесь мы сосредоточились именно на памяти.

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