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() розкриває версії ПЗ, шляхи та змінні оточення, полегшуючи розвідку зловмиснику.