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