Перейти к содержимому
Конфигурация

Исправляем ошибку "Allowed Memory Size Exhausted" в WordPress

Если сайт выдаёт Fatal error: Allowed memory size of 268435456 bytes exhausted, добавьте эту строку в wp-config.php над комментарием / That's all, stop editing! /

Опубликовано

Если сайт выдаёт Fatal error: Allowed memory size of 268435456 bytes exhausted, добавьте эту строку в wp-config.php над комментарием /* That's all, stop editing! */: define( 'WP_MEMORY_LIMIT', '256M' );. Это возвращает большинство сайтов в строй меньше чем за минуту. Но прежде чем закрыть страницу, дочитайте её до конца, потому что повышение лимита — это диагностика, а не лечение. Если сбой возвращается уже на большем числе, настоящая причина — код, который потребляет память без ограничений, и более высокий потолок просто даёт ему больше верёвки.

Что на самом деле означает эта ошибка

PHP отслеживает, сколько памяти выделил каждый запрос. Когда отдельный запрос пытается выделить память сверх memory_limit, заданного в php.ini (или переопределённого WordPress), PHP немедленно убивает запрос с фатальной ошибкой и печатает число байтов, на котором он умер. 268435456 bytes — это 256M. 134217728 — это 128M. 536870912 — это 512M. Число после «tried to allocate» говорит вам о размере последней капли, а не о размере самой проблемы.

WordPress накладывает свои собственные лимиты поверх PHP. WP_MEMORY_LIMIT (по умолчанию 40M, или лимит PHP, если он выше) управляет фронтендом. WP_MAX_MEMORY_LIMIT (по умолчанию 256M) управляет операциями в админке — такими как медиатека и обновление плагинов, которым по делу нужно больше. WordPress при загрузке вызывает ini_set('memory_limit', ...) на основе этих констант — но только если хостинг разрешает ini_set, и только до жёсткого потолка, установленного хостингом. Именно из-за этой последней части редактирование wp-config.php иногда как будто ни на что не влияет.

Исправляем по порядку

1. Повысьте лимит WordPress в wp-config.php. С этого стоит начинать, потому что это обратимо и ничего больше не затрагивает.

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Если вы не уверены, куда вставить эти строки, или хотите заодно правильно задать другие частые константы, наш генератор wp-config сформирует аккуратный блок, который можно вставить как есть. Расположение важно — всё, что ниже строки «stop editing», игнорируется.

2. Если это ничего не дало — хостинг ограничивает PHP. Повысьте memory_limit на уровне PHP. В php.ini:

memory_limit = 256M

На многих виртуальных хостингах напрямую редактировать php.ini нельзя. Попробуйте вместо этого файл .user.ini в корне сайта или задайте значение через .htaccess на связке Apache/mod_php:

php_value memory_limit 256M

Учтите, что php_value в .htaccess выдаёт ошибку 500 на nginx или на связках PHP-FPM, потому что это директива Apache/mod_php. Если после добавления вы получили 500 — вот почему: уберите её и используйте .user.ini.

3. Проверьте значение, которое действительно применилось. Не доверяйте тому, что отредактировали; доверяйте тому, что сообщает PHP. Положите однострочный файл в корень сайта:

<?php echo ini_get('memory_limit');

Откройте его в браузере, посмотрите значение, затем удалите файл. Если после того, как вы задали 256M, там по-прежнему 128M — хостинг переопределяет ваше значение, и нужно связаться с ним или воспользоваться настройкой в панели управления.

То, что большинство руководств пропускают

Повышение лимита — это диагностика. Вот как читать результат.

Если вы задали 256M и сайт держится при обычной нагрузке — у вас был законный потолок, который оказался слишком низким. Обычное дело для сайтов с большими медиатеками, WooCommerce или конструкторами страниц. Готово.

Если вы задали 256M — и снова сбой, потом 512M — и снова сбой, прекратите повышать. Нормальному запросу WordPress не нужно 512M. Когда потребление памяти растёт без потолка, значит что-то зациклилось или накапливается: плагин, загружающий целую таблицу базы данных в массив, add_action, который рекурсивно запускает сам себя, процедура импорта, держащая в памяти все строки сразу, или два плагина, дерущиеся внутри одного хука. Повышение лимита не чинит бесконечный цикл — оно лишь отодвигает сбой на несколько секунд и усложняет его воспроизведение.

Чтобы найти виновника, отключите все плагины и переключитесь на стандартную тему вроде Twenty Twenty-Four. Если ошибка пропала — включайте плагины по одному, пока она не вернётся. Включите лог отладки, чтобы поймать, где именно всё падает:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Строка с фатальной ошибкой в wp-content/debug.log называет файл и номер строки, где был выделен последний кусок памяти. Обычно это и есть цикл — или на один вызов функции от него.

Чего делать не стоит

Не задавайте WP_MEMORY_LIMIT в -1 или 1024M и не забывайте про это. Неограниченная память не чинит утечку; она позволяет запросу-беглецу съесть весь сервер, что может положить все остальные сайты на той же машине и обеспечить вам звонок от хостинга. Потолок — это защитный механизм. Оставьте его.

Не вставляйте ini_set('memory_limit', '512M') в functions.php как основное решение. Для некоторых сбоев это срабатывает слишком поздно — если крах происходит во время загрузки ядра WordPress, ещё до того как выполнится functions.php вашей темы, строка так и не запустится. wp-config.php загружается раньше и является правильным местом.

Не считайте, что это проблема хостинга, и не спешите повышать тариф. Иногда хостинг и правда недостаточно мощный. Но часто ровно тот же сбой переезжает с вами на более дорогой тариф, потому что причина уехала вместе с вашими плагинами. Сначала исключите цикл — это бесплатно.

Не повышайте memory_limit, чтобы исправить ошибку max_execution_time. Это разные лимиты с разными сообщениями. Исчерпание памяти говорит «Allowed memory size … exhausted». Таймаут говорит «Maximum execution time … exceeded». Повышение не того лимита стоит вам впустую потраченного вечера.

Всё ещё не выходит?

Если вы убедились, что действующий лимит и правда 256M или выше, проверили с отключёнными плагинами и стандартной темой, а память всё равно исчерпывается — у вас настоящая утечка, которую стоит выслеживать по логу отладки, а не потолок, который стоит повышать. Зафиксируйте строку с фатальной ошибкой, отметьте, в директорию какого плагина она указывает — и вот ваш баг-репорт. Сначала приведите в порядок базовые константы wp-config.php с помощью генератора wp-config, чтобы точно знать, что лимиты заданы там, где вы думаете, — а затем идите читать лог.