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

MAATRIX

YOURLS выглядит как простейший скрипт: PHP-файл принимает короткий код, дёргает MySQL, отдаёт 301-редирект. Но стоит подключить сервис к рассылке, рекламной кампании или API нескольких проектов — и «лёгкий шортенер» неожиданно начинает тормозить или падать под нагрузкой. Разберёмся, откуда берётся расход памяти, сколько RAM закладывать под разные сценарии и как настроить PHP-FPM и MySQL так, чтобы не переплачивать за сервер и не упереться в лимиты в самый неподходящий момент.

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

YOURLS — это связка из трёх компонентов, каждый из которых ест свою долю RAM:

• Веб-сервер (nginx или Apache) — сам по себе лёгкий, десятки мегабайт на процесс.
• PHP-FPM — на каждый обрабатываемый запрос поднимается воркер-процесс. Именно они съедают основную часть памяти, потому что YOURLS подключает ядро, плагины и вызывает обработчики хуков даже на простом редиректе.
• MySQL/MariaDB — хранит таблицу yourls_url (сами ссылки) и yourls_log (журнал переходов: IP, referer, user-agent, время). Именно yourls_log растёт быстрее всего и определяет, сколько памяти нужно под кэш InnoDB.

Важный нюанс: сам редирект — операция дешёвая (один SELECT по индексу и один INSERT в лог), но она выполняется на каждый клик, а не на каждый заход в админку. Если у вас 50 коротких ссылок и по ним кликают 20 000 раз в день, нагрузка формируется именно кликами, а не количеством самих ссылок в базе.

Отдельно стоит статистика: включённые в YOURLS графики переходов по дням/странам/браузерам строятся агрегирующими запросами по yourls_log, и на таблице в миллионы строк без индексов такой запрос может неожиданно съесть заметный кусок sort_buffer и tmp_table_size.

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

Ниже — ориентировочные цифры для связки nginx + PHP-FPM + MariaDB на одном VPS. Это не измеренный бенчмарк, а практическая раскладка под типовые профили нагрузки — у вас может отличаться в зависимости от количества плагинов и активности ботов-краулеров, которые тоже дёргают редиректы.

Если YOURLS живёт на сервере не один, а вместе с другими сайтами (WordPress, панелью, ботами), RAM считается по совокупности сервисов — методику расчёта под общую нагрузку я разбирал в статье что делать при нехватке RAM. Сам подход настройки PHP+MySQL под ограниченный сервер похож на расчёт RAM для WordPress — тоже LAMP-стек, только вместо CMS у вас редиректор.

PHP-FPM: сколько воркеров реально нужно

По умолчанию многие дистрибутивы ставят PHP-FPM с pm = dynamic и щедрыми лимитами, которые на VPS с 1 ГБ RAM могут привести к OOM-килу при всплеске запросов. Правило простое: один воркер YOURLS в среднем занимает 25–40 МБ (зависит от количества активных плагинов), значит на 1 ГБ RAM с запасом под MySQL и систему разумно ограничить пул 8–10 воркерами.

Пример конфига /etc/php/8.3/fpm/pool.d/yourls.conf под сервер с 1 ГБ RAM:

[yourls]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm-yourls.sock

pm = dynamic
pm.max_children = 10
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 500

pm.max_requests важен отдельно: он перезапускает воркер после N запросов, подчищая утечки памяти от плагинов, которые не всегда аккуратно освобождают ресурсы. На небольшом сервере это дешёвая страховка от постепенного роста потребления RAM за сутки.

Проверить, сколько реально ест каждый воркер, можно так:

ps --sort=-rss -eo rss,pid,cmd | grep 'php-fpm: pool yourls' | head

Если цифры заметно выше 40 МБ на процесс — ищите тяжёлые плагины (особенно генераторы QR-кодов и интеграции с внешними API геолокации по IP) или проверяйте, не включён ли лишний debug-режим.

MySQL/MariaDB: буфер InnoDB — самое узкое место

Таблица yourls_log — единственное место в YOURLS, которое растёт без ограничений: каждый клик — новая строка. Через год активной работы публичного шортенера она вполне может разрастись до нескольких гигабайт. Если innodb_buffer_pool_size меньше рабочего набора данных, каждый запрос статистики начинает читать с диска, а не из памяти — это самая частая причина, почему YOURLS «внезапно тормозит» через несколько месяцев эксплуатации, хотя количество ссылок почти не изменилось.

Рекомендации по /etc/mysql/mariadb.conf.d/50-server.cnf в зависимости от общей RAM сервера:

# Сервер 1 ГБ RAM (YOURLS + немного другого)
innodb_buffer_pool_size = 256M
innodb_buffer_pool_instances = 1
max_connections = 40
tmp_table_size = 32M
max_heap_table_size = 32M

# Сервер 2 ГБ RAM (YOURLS основная нагрузка)
innodb_buffer_pool_size = 768M
innodb_buffer_pool_instances = 1
max_connections = 80
tmp_table_size = 64M
max_heap_table_size = 64M

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

SELECT table_name,
       ROUND((data_length + index_length) / 1024 / 1024, 1) AS size_mb
FROM information_schema.tables
WHERE table_schema = 'yourls_db'
ORDER BY size_mb DESC;

Если yourls_log заметно перевешивает yourls_url и продолжает расти, имеет смысл раз в квартал архивировать старые записи (например, старше года) в отдельную таблицу или во внешнее хранилище — это снижает требования и к буферу, и к бэкапам. Сам процесс регулярного резервного копирования MySQL под VPS с ограниченной памятью я разбирал в статье про настройку бэкапа MySQL — для журнала кликов подойдёт тот же принцип, только с ротацией.

Кэширование редиректов: снимаем нагрузку с MySQL

На публичном шортенере с высоким трафиком есть смысл не бить каждым кликом по MySQL напрямую, а держать самые популярные короткие коды в памяти. Два практичных способа:

OPcache для PHP — обязателен в любом случае, экономит CPU и косвенно память за счёт того, что PHP не перекомпилирует байт-код на каждый запрос:

; /etc/php/8.3/fpm/conf.d/10-opcache.ini
opcache.enable=1
opcache.memory_consumption=64
opcache.max_accelerated_files=4000
opcache.validate_timestamps=0

validate_timestamps=0 фиксирует кэш до ручного рестарта PHP-FPM после обновления кода — на проде это нормально, просто не забывайте перезапускать сервис после деплоя.

Кэш на уровне редиректов через плагин — в экосистеме YOURLS есть плагины, кэширующие пары «короткий код → целевой URL» в APCu или Memcached, чтобы не ходить в MySQL на каждый переход. Для сервиса с десятками тысяч кликов в день это снимает основную нагрузку с БД, оставляя MySQL только запись в лог (можно даже сделать её асинхронной через очередь, если трафик совсем большой). На VPS с 2 ГБ RAM под APCu достаточно выделить 32–64 МБ — этого хватает на кэш тысяч самых активных ссылок.

Что делать при явной нехватке памяти

Симптомы нехватки RAM для YOURLS обычно узнаваемы:

• В логах PHP-FPM (/var/log/php8.3-fpm.log) появляются записи WARNING: [pool yourls] server reached pm.max_children.
• dmesg | grep -i oom показывает, что ядро убило процесс mysqld или php-fpm.
• Редиректы начинают отвечать с задержкой в секунды вместо десятков миллисекунд.

Первая мера — включить своп как временную подушку безопасности (не решение, а страховка от жёсткого падения процесса):

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Если своп начинает использоваться регулярно (проверяйте free -h раз в день несколько дней подряд), это сигнал не «настроить получше», а «нужно больше RAM» — своп для диска на SSD спасает от аварийного падения, но заметно медленнее реальной памяти, и под нагрузкой в тысячи кликов в час это будет ощущаться пользователями как подвисающие переходы. В таком случае логичнее заранее взять VPS с запасом по памяти, чем донастраивать урезанный тариф под растущий трафик.

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