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

Виправлення помилки "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');

Завантажте його у браузері, прочитайте значення, потім видаліть файл. Якщо він досі показує 128M після того, як ви встановили 256M, ваш хостинг перевизначає ваше значення, і вам потрібно звернутися до нього або скористатися налаштуванням у панелі керування.

Частина, яку більшість посібників пропускає

Підвищення ліміту — це діагностика. Ось як читати результат.

Якщо ви встановили 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, щоб бути впевненими, що ліміти встановлені там, де ви думаєте — а потім читайте журнал.