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

MAATRIX

«Сколько RAM нужно для WordPress» — вопрос, на который отвечают и «512 МБ за глаза», и «меньше 8 ГБ не берите»; обе цифры взяты с потолка. Официальные требования к серверу у WordPress про память молчат: там только версии PHP и MySQL. Цифру задают три величины — сколько воркеров PHP-FPM разрешено, сколько весит каждый и что осталось базе. Ниже — разбор по компонентам, команды замера и конфиги под 2 и 4 ГБ.

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

Ориентиры для nginx 1.28 + PHP-FPM 8.3 + MariaDB 11.4 на Ubuntu 24.04 с кешем страниц. Без кеша сдвигайте на строку вверх.

Мультисайту или десятку сайтов агентства закладывайте 16–32 ГБ. Про гигабайт честно: он работает в одном раскладе — один сайт, кеш страниц, 3–4 воркера, innodb_buffer_pool_size = 128M и swap на 2 ГБ. Обновление плагинов из админки там — рулетка: оно держит воркер, распаковку архива и запросы к базе разом.

Главное из таблицы: сам WordPress почти никогда не требует 8 ГБ. Столько требует окружение — десяток параллельных воркеров с тяжёлыми плагинами и буферный пул InnoDB.

memory_limit — это не память сервера

Самая дорогая путаница в теме. memory_limit в PHP — потолок одного запроса, а не сервера: он не резервирует память, а убивает скрипт, перешагнувший планку.

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted
(tried to allocate 262144 bytes) in /var/www/site/wp-includes/functions.php on line 6114

134217728 байт — это 128 МБ, дефолт сборок Ubuntu и Debian. Разбор самого падения — в статье про белый экран смерти; здесь важна арифметика вокруг потолка.

Дефолтные 40M в wp-includes/default-constants.php пугают зря: WordPress зовёт wp_raise_memory_limit(), а тот только повышает лимит и никогда не понижает. При memory_limit = 256M строка define('WP_MEMORY_LIMIT', '40M') не сделает ничего — потолок задаёт PHP.

Отсюда ловушка, из-за которой сервер и умирает. memory_limit = 512M при pm.max_children = 12 — теоретические 6 ГБ на машине, где физически 4. Пока запросы лёгкие, всё держится; на первом импорте товаров несколько воркеров упираются в потолок разом, и приходит ядро.

Out of memory: Killed process 921 (mariadbd) total-vm:2103448kB, anon-rss:512980kB,
file-rss:0kB, shmem-rss:0kB, UID:107 pgtables:1420kB oom_score_adj:0

OOM killer выбирает по oom_score, а самый жирный процесс на сайте — база: PHP выжил, MariaDB нет, посетитель видит «Error establishing a database connection». Разумные значения — 256M обычному сайту и 384–512M только админскому пулу.

Из чего складывается память сайта на WordPress

Замеры на Ubuntu 24.04 с PHP 8.3, MariaDB 11.4 и nginx 1.28; погрешность — процентов двадцать.

Наивный подсчёт ломают две вещи. Первая: разделяемая память OPcache считается в RSS каждого воркера. При opcache.memory_consumption=128 двенадцать воркеров дают в ps полтора лишних гигабайта — сегмент один на всех, складывать RSS бессмысленно, нужен PSS. Вторая: MySQL 8.4 тяжелее MariaDB примерно на 200 МБ при равных настройках, и на двухгигабайтной машине эта разница решает.

Как измерить свой расход, а не гадать по чужим цифрам

free -m на работающем сайте с 4 ГБ:

               total   used   free   shared  buff/cache   available
Mem:            3919   1604    210      112        2104        2015

Смотрите на available, а не на free: кеш ядро отдаст по требованию, и «свободно 210 МБ» — нормальная картина здорового Linux.

ps --no-headers -o rss -C php-fpm8.3 | awk '{s+=
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть WordPress
Из чего складывается память сайта на WordPress
Замеры на Ubuntu 24.04 с PHP 8.3, MariaDB 11.4 и nginx 1.28; погрешность — процентов двадцать.
Компонент
RSS
Комментарий
Ubuntu 24.04 после загрузки (systemd, journald, sshd)
190–260 МБ
вычитайте сразу
nginx 1.28 и мастер PHP-FPM
35–60 МБ
почти не растёт
Воркер: чистый WordPress, тема Twenty Twenty-Five
45–65 МБ
PSS 30–45 МБ
Воркер: 20–30 плагинов, конструктор страниц
110–170 МБ
пик на рендере редактора
Воркер: WooCommerce с расширениями
140–220 МБ
самый тяжёлый профиль
MariaDB 11.4, innodb_buffer_pool_size = 256M
330–420 МБ
performance_schema выключен по умолчанию
MySQL 8.4 с той же настройкой
480–620 МБ
из них 180–260 МБ — performance_schema
Redis 7 как объектный кеш среднего сайта
40–140 МБ
пустой — 6–8 МБ
Ночной restic или borg во время прогона
120–350 МБ
частая причина утренних падений
Наивный подсчёт ломают две вещи. Первая: разделяемая память OPcache считается в RSS каждого воркера. При opcache.memory_consumption=128 двенадцать воркеров дают в ps полтора лишних гигабайта — сегмент один на всех, складывать RSS бессмысленно, нужен PSS. Вторая: MySQL 8.4 тяжелее MariaDB примерно на 200 МБ при равных настройках, и на двухгигабайтной машине эта разница решает.
Как измерить свой расход, а не гадать по чужим цифрам
free -m на работающем сайте с 4 ГБ:
               total   used   free   shared  buff/cache   available
Mem:            3919   1604    210      112        2104        2015
Смотрите на available, а не на free: кеш ядро отдаст по требованию, и «свободно 210 МБ» — нормальная картина здорового Linux.
ps --no-headers -o rss -C php-fpm8.3 | awk '{s+=$1; n++} END {print n" воркеров, средний RSS "int(s/n/1024)" МБ"}'
apt install -y smem && smem -t -k -P php-fpm | tail -3
cat /sys/fs/cgroup/system.slice/php8.3-fpm.service/memory.peak
smem даёт PSS — честную долю разделяемых страниц: 12 воркеров по 148 МБ RSS и всего 74 МБ PSS. А memory.peak в cgroup — это пик, а не текущее значение; именно он решает, хватит ли памяти.
Аппетит самого WordPress мерят через WP-CLI: разница между запусками и есть цена плагинов.
wp eval 'echo size_format(memory_get_peak_usage(true)),"\n";'
wp --skip-plugins --skip-themes eval 'echo size_format(memory_get_peak_usage(true)),"\n";'
На магазине это обычно 96 MB против 22 MB — конкретные 74 мегабайта в каждом воркере. Постранично то же покажет Query Monitor.
Проверьте историю смертей: часто сервер уже убивал процессы, а это списывали на «глюки хостинга».
dmesg -T | grep -iE "killed process|out of memory"
grep -c "server reached pm.max_children" /var/log/php8.3-fpm.log
journalctl -u php8.3-fpm --since "-7d" | grep "exited on signal 9"
Строка [pool www] child 20481 exited on signal 9 (SIGKILL) — воркер, убитый ядром, а не упавший сам; на фронте это 502 Bad Gateway.
Формула pm.max_children и рабочие конфиги
Число воркеров — настройка, которая напрямую переводит гигабайты в устойчивость сайта.
pm.max_children = (RAM − ОС − база − Redis − nginx − запас) / средний PSS воркера
Для 2 ГБ: (2048 − 220 − 360 − 60 − 30 − 250) = 1128 МБ, делим на 75 МБ, получаем 15. Ставить 15 не надо: на одном ядре больше 6–8 параллельных PHP-процессов только удлиняют очередь. Берите минимум из «сколько влезет по памяти» и «vCPU × 4».
Конфиг /etc/php/8.3/fpm/pool.d/www.conf для 2 ГБ и 1–2 vCPU:
pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500
php_admin_value[memory_limit] = 256M
pm.status_path = /fpm-status
pm.max_requests = 500 обязателен: воркер перезапускается каждые 500 запросов, и утечки в плагинах не копятся сутками — без него RSS воркера за неделю уезжает с 80 до 300 МБ. Для 4 ГБ, 2 vCPU и WooCommerce: pm.max_children = 10, memory_limit = 384M. Хватает ли — видно по pm.status_path: растёт max children reached и не пустеет listen queue — воркеров мало.
На слабой машине помогает pm = ondemand с pm.process_idle_timeout = 10s: простаивающие воркеры отдают память ценой 50–150 мс на «холодном» запросе. Нескольким сайтам нужен свой пул на каждый, со своим user и pm.max_children: в общем пуле один сайт под наплывом занимает все воркеры, и остальные встают.
Как ужать сайт до 2 ГБ и не потерять скорость
Кеш страниц — рычаг номер один, остальное вместе слабее. Закешированный ответ отдаёт nginx: PHP не запускается, память не тратится.
fastcgi_cache_path /var/cache/nginx/wp levels=1:2 keys_zone=WPCACHE:20m
                   max_size=1g inactive=12h use_temp_path=off;
Зона 20m — только ключи (около 160 тысяч страниц), тела лежат на диске. Замер wrk -t2 -c50 -d30s на 2 vCPU / 4 ГБ: без кеша каталог WooCommerce отдаёт 11 запросов в секунду и занимает все 12 воркеров, из кеша — около 4200 при трёх простаивающих. Ограничение честное: корзину, оформление, кабинет и залогиненных кешировать нельзя.
if ($http_cookie ~* "wordpress_logged_in|woocommerce_items_in_cart") { set $skip_cache 1; }
if ($request_uri ~* "/(cart|checkout|my-account|wp-admin)/") { set $skip_cache 1; }
Поэтому магазин с сотней одновременных покупателей упирается в память даже с идеальным кешем.
База. Буферный пул подбирают не по проценту от RAM, а по размеру данных:
SELECT ROUND(SUM(data_length+index_length)/1024/1024) mb FROM information_schema.tables WHERE engine='InnoDB';
База на 180 МБ целиком влезает в пул 256 МБ, и гигабайт там — выброшенная память. Правило: пул ≈ размер данных +20%, но не больше 30–40% RAM. Дальше max_connections = pm.max_children + 10 (дефолтные 151 зря резервируют потоковые буферы) и performance_schema = OFF на MySQL 8 — минус 200 МБ одной строкой. Больше конфигов — в оптимизации MySQL под 1 ГБ RAM.
OPcache. find /var/www/site -name '*.php' | wc -l на сборке с WooCommerce даёт 14382 файла, а дефолт opcache.max_accelerated_files=10000 заставляет кеш вытеснять сам себя — сайт тормозит на ровном месте. Ставьте 30000 и opcache.memory_consumption=192. Тонкость: у CLI свой OPcache, статус смотрите через cachetool по FPM-сокету, а не через wp eval.
Redis — всегда с потолком, иначе объектный кеш растёт, пока OOM killer не заберёт базу: maxmemory 128mb, maxmemory-policy allkeys-lru, save "" (форк для RDB-снимка на пике просит вдвое больше памяти).
Swap — подушка, а не сиденье: он спасает от OOM, но своппирующая база отдаёт страницы по пять секунд.
fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
echo 'vm.swappiness=10' > /etc/sysctl.d/99-swap.conf
Ненулевые si/so в vmstat 1 — знак, что вопрос решается памятью, а не тюнингом. Остальные приёмы — в ускорении WordPress на слабом VPS.
Какой сервер взять в MAATRIX под WordPress
WordPress упирается в память раньше, чем в процессор: ядра нужны рендеру некешируемых страниц, память — числу параллельных посетителей. Выбирая между вторым ядром и удвоением RAM, берите второе.
Минимум: 1–2 vCPU, 2 ГБ RAM, 25 ГБ NVMe. Один сайт, pm.max_children = 8, memory_limit = 256M, пул InnoDB 256 МБ, кеш включён — блог с несколькими тысячами посетителей в день. Ограничения прямо: конструкторы страниц в редакторе подтормаживают, WooCommerce тут делать нечего, а бэкап лучше слать наружу, а не паковать локально.
Комфортный вариант: 2–4 vCPU, 4–8 ГБ RAM, 40–60 ГБ NVMe. Помещаются 10–12 воркеров с тяжёлыми плагинами, Redis, staging-копия и локальные дампы. Для WooCommerce с большим каталогом сразу берите 8 ГБ: буферный пул должен вмещать базу целиком, иначе фильтры идут на диск.
Локация — UK, Лондон, если аудитория в Европе: узел стоит на LINX, RTT до большинства европейских городов укладывается в 10–30 мс, а это напрямую TTFB и Core Web Vitals. Второй довод — данные: регистрации, комментарии и заказы WooCommerce почти всегда попадают под GDPR. Если посетители из России, честнее RU-локация — минимальный пинг и 152-ФЗ; для рынка США — US.
Ставить руками ничего не нужно: WordPress есть в каталоге apps.maatrix.io и ставится автоматически при заказе на Ubuntu или Debian. Доступы к сайту, базе и SSH появляются в личном кабинете, раздел «Доступ»; дальше правите pm.max_children и innodb_buffer_pool_size по формулам выше. Оплата картами российских банков, по СБП или криптовалютой — иностранная карта не нужна, хотя сервер в Лондоне.
Развернуть за пару минут
Готовый образ на VPS MAATRIX: NVMe, AMD EPYC, root-доступ. Локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.
Развернуть WordPress
; n++} END {print n" воркеров, средний RSS "int(s/n/1024)" МБ"}'
apt install -y smem && smem -t -k -P php-fpm | tail -3
cat /sys/fs/cgroup/system.slice/php8.3-fpm.service/memory.peak

smem даёт PSS — честную долю разделяемых страниц: 12 воркеров по 148 МБ RSS и всего 74 МБ PSS. А memory.peak в cgroup — это пик, а не текущее значение; именно он решает, хватит ли памяти.

Аппетит самого WordPress мерят через WP-CLI: разница между запусками и есть цена плагинов.

wp eval 'echo size_format(memory_get_peak_usage(true)),"\n";'
wp --skip-plugins --skip-themes eval 'echo size_format(memory_get_peak_usage(true)),"\n";'

На магазине это обычно 96 MB против 22 MB — конкретные 74 мегабайта в каждом воркере. Постранично то же покажет Query Monitor.

Проверьте историю смертей: часто сервер уже убивал процессы, а это списывали на «глюки хостинга».

dmesg -T | grep -iE "killed process|out of memory"
grep -c "server reached pm.max_children" /var/log/php8.3-fpm.log
journalctl -u php8.3-fpm --since "-7d" | grep "exited on signal 9"

Строка [pool www] child 20481 exited on signal 9 (SIGKILL) — воркер, убитый ядром, а не упавший сам; на фронте это 502 Bad Gateway.

Формула pm.max_children и рабочие конфиги

Число воркеров — настройка, которая напрямую переводит гигабайты в устойчивость сайта.

pm.max_children = (RAM − ОС − база − Redis − nginx − запас) / средний PSS воркера

Для 2 ГБ: (2048 − 220 − 360 − 60 − 30 − 250) = 1128 МБ, делим на 75 МБ, получаем 15. Ставить 15 не надо: на одном ядре больше 6–8 параллельных PHP-процессов только удлиняют очередь. Берите минимум из «сколько влезет по памяти» и «vCPU × 4».

Конфиг /etc/php/8.3/fpm/pool.d/www.conf для 2 ГБ и 1–2 vCPU:

pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500
php_admin_value[memory_limit] = 256M
pm.status_path = /fpm-status

pm.max_requests = 500 обязателен: воркер перезапускается каждые 500 запросов, и утечки в плагинах не копятся сутками — без него RSS воркера за неделю уезжает с 80 до 300 МБ. Для 4 ГБ, 2 vCPU и WooCommerce: pm.max_children = 10, memory_limit = 384M. Хватает ли — видно по pm.status_path: растёт max children reached и не пустеет listen queue — воркеров мало.

На слабой машине помогает pm = ondemand с pm.process_idle_timeout = 10s: простаивающие воркеры отдают память ценой 50–150 мс на «холодном» запросе. Нескольким сайтам нужен свой пул на каждый, со своим user и pm.max_children: в общем пуле один сайт под наплывом занимает все воркеры, и остальные встают.

Как ужать сайт до 2 ГБ и не потерять скорость

Кеш страниц — рычаг номер один, остальное вместе слабее. Закешированный ответ отдаёт nginx: PHP не запускается, память не тратится.

fastcgi_cache_path /var/cache/nginx/wp levels=1:2 keys_zone=WPCACHE:20m
                   max_size=1g inactive=12h use_temp_path=off;

Зона 20m — только ключи (около 160 тысяч страниц), тела лежат на диске. Замер wrk -t2 -c50 -d30s на 2 vCPU / 4 ГБ: без кеша каталог WooCommerce отдаёт 11 запросов в секунду и занимает все 12 воркеров, из кеша — около 4200 при трёх простаивающих. Ограничение честное: корзину, оформление, кабинет и залогиненных кешировать нельзя.

if ($http_cookie ~* "wordpress_logged_in|woocommerce_items_in_cart") { set $skip_cache 1; }
if ($request_uri ~* "/(cart|checkout|my-account|wp-admin)/") { set $skip_cache 1; }

Поэтому магазин с сотней одновременных покупателей упирается в память даже с идеальным кешем.

База. Буферный пул подбирают не по проценту от RAM, а по размеру данных:

SELECT ROUND(SUM(data_length+index_length)/1024/1024) mb FROM information_schema.tables WHERE engine='InnoDB';

База на 180 МБ целиком влезает в пул 256 МБ, и гигабайт там — выброшенная память. Правило: пул ≈ размер данных +20%, но не больше 30–40% RAM. Дальше max_connections = pm.max_children + 10 (дефолтные 151 зря резервируют потоковые буферы) и performance_schema = OFF на MySQL 8 — минус 200 МБ одной строкой. Больше конфигов — в оптимизации MySQL под 1 ГБ RAM.

OPcache. find /var/www/site -name '*.php' | wc -l на сборке с WooCommerce даёт 14382 файла, а дефолт opcache.max_accelerated_files=10000 заставляет кеш вытеснять сам себя — сайт тормозит на ровном месте. Ставьте 30000 и opcache.memory_consumption=192. Тонкость: у CLI свой OPcache, статус смотрите через cachetool по FPM-сокету, а не через wp eval.

Redis — всегда с потолком, иначе объектный кеш растёт, пока OOM killer не заберёт базу: maxmemory 128mb, maxmemory-policy allkeys-lru, save "" (форк для RDB-снимка на пике просит вдвое больше памяти).

Swap — подушка, а не сиденье: он спасает от OOM, но своппирующая база отдаёт страницы по пять секунд.

fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
echo 'vm.swappiness=10' > /etc/sysctl.d/99-swap.conf

Ненулевые si/so в vmstat 1 — знак, что вопрос решается памятью, а не тюнингом. Остальные приёмы — в ускорении WordPress на слабом VPS.

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

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

Минимум: 1–2 vCPU, 2 ГБ RAM, 25 ГБ NVMe. Один сайт, pm.max_children = 8, memory_limit = 256M, пул InnoDB 256 МБ, кеш включён — блог с несколькими тысячами посетителей в день. Ограничения прямо: конструкторы страниц в редакторе подтормаживают, WooCommerce тут делать нечего, а бэкап лучше слать наружу, а не паковать локально.

Комфортный вариант: 2–4 vCPU, 4–8 ГБ RAM, 40–60 ГБ NVMe. Помещаются 10–12 воркеров с тяжёлыми плагинами, Redis, staging-копия и локальные дампы. Для WooCommerce с большим каталогом сразу берите 8 ГБ: буферный пул должен вмещать базу целиком, иначе фильтры идут на диск.

Локация — UK, Лондон, если аудитория в Европе: узел стоит на LINX, RTT до большинства европейских городов укладывается в 10–30 мс, а это напрямую TTFB и Core Web Vitals. Второй довод — данные: регистрации, комментарии и заказы WooCommerce почти всегда попадают под GDPR. Если посетители из России, честнее RU-локация — минимальный пинг и 152-ФЗ; для рынка США — US.

Ставить руками ничего не нужно: WordPress есть в каталоге apps.maatrix.io и ставится автоматически при заказе на Ubuntu или Debian. Доступы к сайту, базе и SSH появляются в личном кабинете, раздел «Доступ»; дальше правите pm.max_children и innodb_buffer_pool_size по формулам выше. Оплата картами российских банков, по СБП или криптовалютой — иностранная карта не нужна, хотя сервер в Лондоне.

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