PHP настройка: memory_limit и upload_max_filesize

Где хранятся настройки PHP

PHP-параметры можно задавать в нескольких местах. Приоритет (от высшего к низшему): ini_set() в коде → .user.ini → .htaccess → php.ini. Изменения в php.ini требуют перезапуска PHP-FPM.

Ключевые параметры PHP

Изменение через php.ini

# Найти актуальный php.ini
php --ini

# Редактировать (для PHP-FPM)
sudo nano /etc/php/8.2/fpm/php.ini

memory_limit = 512M
upload_max_filesize = 128M
post_max_size = 130M
max_execution_time = 300
max_input_time = 300
max_input_vars = 5000

Изменение через .user.ini (для shared hosting)

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

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 68M
max_execution_time = 120

Изменение через .htaccess (для Apache)

php_value memory_limit 256M
php_value upload_max_filesize 64M
php_value post_max_size 68M
php_value max_execution_time 120

Изменение в коде PHP (временно)

<?php
ini_set('memory_limit', '512M');
ini_set('max_execution_time', '300');
set_time_limit(300);

Применение изменений php.ini

sudo systemctl reload php8.2-fpm

# Проверка применённых значений
php -r "echo ini_get('memory_limit');"

Реальные ошибки и их разбор

Allowed memory size exhausted

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/index.php on line 42

134217728 байт — это 128 МБ, значение memory_limit по умолчанию. Скрипт запросил ещё один блок памяти (в примере — 20480 байт) и упёрся в потолок. Типичные причины: загрузка большого файла в переменную целиком, обработка массива из тысяч записей без генераторов, утечка памяти в цикле. Поднятие memory_limit лечит симптом, но если потребление растёт с каждым запуском — ищите утечку, а не увеличивайте лимит бесконечно.

Maximum execution time exceeded

Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/import.php on line 15

Скрипт выполнялся дольше, чем разрешает max_execution_time. Это время работы самого PHP, а не ожидание клиента. Для длительных импортов правильнее не поднимать лимит до бесконечности на весь сайт, а выносить задачу в очередь — например, через отдельный пул PHP-FPM с собственными таймаутами, — где max_execution_time можно смело ставить в 0.

POST Content-Length exceeds the limit

PHP Warning:  POST Content-Length of 15728640 bytes exceeds the limit of 8388608 bytes in Unknown on line 0

Строка in Unknown on line 0 — не баг, а особенность: PHP отклоняет тело запроса ещё до передачи управления коду, поэтому файла и номера строки просто нет. При этой ошибке весь массив $_POST будет пустым, а не только файл — это часто путает при отладке обычных форм.

Когда правки php.ini не помогают

• Сайт работает через Nginx — тело запроса режется на уровне веб-сервера директивой client_max_body_size ещё до того, как дойдёт до PHP-FPM. Проверьте и её.
• Хостинг запускает PHP как CGI под suPHP/suexec — там .htaccess с php_value обычно игнорируется, работает только .user.ini.
• .user.ini подхватывается не мгновенно: интервал перечитывания задаёт user_ini.cache_ttl (по умолчанию 300 секунд). Сразу после правки старое значение может ещё действовать.
• Директива помечена как PHP_INI_SYSTEM (например, disable_functions) — такие параметры нельзя менять через .htaccess, .user.ini или ini_set(), только через php.ini и перезапуск FPM.

Проверка результата

Создайте временный файл info.php с phpinfo() и откройте его в браузере — там для каждой директивы есть две колонки:

Если Local Value не совпадает с ожидаемым — правка не долетела: проверьте, тот ли php.ini редактировали (php --ini в консоли и phpinfo() в браузере могут указывать на разные файлы для CLI и FPM), и не забыли ли перезагрузить FPM.

# Быстрая проверка без браузера
php -i | grep -E "memory_limit|upload_max_filesize|post_max_size"

# Проверка веб-версии через curl к тестовому info.php
curl -s https://example.com/info.php | grep -A1 "upload_max_filesize"

После проверки обязательно удалите info.php — phpinfo() раскрывает версии ПО, пути и переменные окружения, облегчая разведку злоумышленнику.