Как увеличить memory_limit в PHP: 5 рабочих способов

Вы столкнулись с ошибкой Fatal error: Allowed memory size of 134217728 bytes exhausted или сайт просто упал с белым экраном смерти? В 70% случаев причина одна — PHP исчерпал выделенный лимит оперативной памяти.

По умолчанию в большинстве хостингов memory_limit установлен на 40-128MB. Для современных WordPress-сайтов с Elementor, WooCommerce или тяжелыми плагинами этого критически мало. В этом руководстве разберём 5 рабочих способов увеличить лимит — от самого надёжного до резервного.

Как проверить текущий memory_limit

Прежде чем менять настройки, нужно узнать, какой лимит установлен сейчас.

Через PHP-скрипт:

<?php
// Создайте файл info.php в корне сайта
phpinfo();
?>

Откройте https://ваш-сайт.ru/info.php и найдите строку memory_limit. После проверки обязательно удалите файл — он раскрывает конфигурацию сервера.

Через WordPress-админку:

Перейдите в Инструменты → Здоровье сайта → вкладка «Инфо» → раздел «Сервер». Там будет точное значение лимита.

Через WP-CLI (если установлен):

wp eval 'echo ini_get("memory_limit");'

Способ 1: Редактирование php.ini (самый надёжный)

Если у вас есть доступ к главному конфигу PHP — это лучший способ. Изменения применятся ко всем сайтам на сервере.

Где найти php.ini:

# Для Linux (через SSH)
php --ini

# Типичные расположения:
/etc/php/8.2/apache2/php.ini      # Ubuntu + Apache
/etc/php/8.2/fpm/php.ini          # Ubuntu + PHP-FPM
/usr/local/etc/php/php.ini        # CentOS / Docker

Что изменить:

; Найдите эти строки и измените значения
memory_limit = 512M
post_max_size = 64M
upload_max_filesize = 64M
max_execution_time = 300

Важно: post_max_size должен быть больше upload_max_filesize, а memory_limit — больше post_max_size. Иначе загрузка больших файлов будет падать.

После изменений перезагрузите PHP:

# Для Apache
sudo systemctl restart apache2

# Для PHP-FPM
sudo systemctl restart php8.2-fpm

# Для Nginx + PHP-FPM
sudo systemctl restart nginx && sudo systemctl restart php8.2-fpm

Способ 2: Через .htaccess (только Apache)

Если php.ini недоступен, но сервер работает на Apache — используйте .htaccess в корне сайта.

# Добавьте в начало .htaccess
php_value memory_limit 512M
php_value post_max_size 64M
php_value upload_max_filesize 64M
php_value max_execution_time 300

Ограничения:

  • Работает только если Apache запущен как модуль (mod_php)
  • Не работает с PHP-FPM, FastCGI или Nginx
  • Может вызвать ошибку 500, если хостинг запретил переопределение

Если после добавления этих строк сайт упал с ошибкой 500 — удалите их и переходите к следующему способу.

Способ 3: Через wp-config.php (только WordPress)

Самый простой способ для WordPress-сайтов, когда нет доступа к серверным конфигам.

// Добавьте ЭТИ строки в wp-config.php ПЕРЕД "That's all, stop editing!"
define( 'WP_MEMORY_LIMIT', '256M' );       // Для фронтенда
define( 'WP_MAX_MEMORY_LIMIT', '512M' );   // Для админки

Нюансы:

  • WordPress не может установить значение выше, чем в php.ini на сервере
  • Если в php.ini стоит 128M, то WP_MEMORY_LIMIT 256M не сработает
  • WP_MAX_MEMORY_LIMIT применяется только в админке (при загрузке медиа, импорте)

Этот способ мы уже упоминали в статье про белый экран смерти WordPress — там он помогает при WSOD из-за нехватки памяти.

Способ 4: Через .user.ini (для PHP-FPM и FastCGI)

Современный стандарт для shared-хостингов с PHP-FPM. Работает там, где .htaccess бессилен.

Создайте файл .user.ini в корне сайта:

memory_limit = 512M
post_max_size = 64M
upload_max_filesize = 64M
max_execution_time = 300

Особенности:

  • Изменения применяются не мгновенно — кэш .user.ini обновляется раз в 5 минут
  • Чтобы ускорить применение, добавьте user_ini.cache_ttl = 60 в главный php.ini
  • Работает на большинстве современных shared-хостингов (Beget, Timeweb, Reg.ru)

Способ 5: Через ini_set() в коде (резервный вариант)

Самый ненадёжный способ — меняет лимит только для текущего скрипта и только если в php.ini разрешено переопределение.

// В начале functions.php или конкретного скрипта
ini_set( 'memory_limit', '512M' );
ini_set( 'max_execution_time', 300 );

Когда использовать:

  • Только для конкретных тяжёлых скриптов (импорт данных, генерация отчётов)
  • Когда другие способы невозможны
  • Как временное решение до получения доступа к конфигам

Многие хостинги блокируют ini_set('memory_limit') в целях безопасности — будьте готовы, что способ может не сработать.

Какой способ выбрать: сравнительная таблица

Способ Надёжность Сложность Область действия
php.ini Высокая Средняя Весь сервер
.htaccess Средняя Низкая Один сайт (Apache)
wp-config.php Средняя Очень низкая Только WordPress
.user.ini Высокая Низкая Один сайт (PHP-FPM)
ini_set() Низкая Очень низкая Один скрипт

Что делать, если лимит не увеличивается

Вы всё сделали правильно, но phpinfo() по-прежнему показывает старое значение. Вот основные причины:

1. Хостинг запрещает переопределение

На shared-хостингах часто установлен жёсткий лимит через php_admin_value, который нельзя перебить. Решение — написать в поддержку с просьбой увеличить лимит или сменить тариф.

2. Несколько версий PHP на сервере

Вы редактируете php.ini для PHP 7.4, а сайт работает на PHP 8.2. Проверьте версию PHP через phpinfo() и редактируйте соответствующий конфиг.

3. Кэш OPcache

PHP кэширует конфигурацию. После изменений выполните:

# Очистка OPcache
sudo service php8.2-fpm restart

# Или через PHP-скрипт
<?php opcache_reset(); ?>

4. Файл .user.ini не применяется

Проверьте права доступа: файл должен быть 644. Также убедитесь, что user_ini.filename в php.ini не переопределён в другое имя.

Best practices: сколько памяти реально нужно

Не ставьте memory_limit «с запасом» — это плохая практика. Вот адекватные значения для разных задач:

  • Простой WordPress-блог — 128-256M
  • WooCommerce магазин — 256-512M
  • Сайт на Elementor + 20 плагинов — 512M
  • Laravel / Symfony приложение — 256-512M
  • Тяжёлый импорт/экспорт данных — 1-2G (временно)

Если вашему сайту нужно больше 512M постоянно — это сигнал о проблемах в коде (утечки памяти, неоптимизированные запросы). Используйте Query Monitor или Blackfire для профилирования.

Что делать, если проблема не решается?

Сайт падает при конкретной операции

Если ошибка возникает только при импорте или генерации отчёта — не увеличивайте глобальный лимит. Вместо этого временно поднимите его через ini_set() именно в этом скрипте, а после выполнения верните обратно.

Хостинг не даёт увеличить лимит

Рассмотрите переход на VPS/VDS — там вы полностью контролируете конфигурацию PHP. Для WordPress хорошо подходят связки с Docker (смотрите наше руководство по устранению OOMKilled при настройке контейнеров).

Память растёт со временем

Если memory_limit приходится повышать регулярно — это утечка. Проверьте плагины через Query Monitor, отключите подозрительные и рассмотрите профилирование кода.