Перейти к содержимому
Гурупрактик
АЙТИ ПОД КЛЮЧ
Связаться
Гурупрактик
АЙТИ ПОД КЛЮЧ
Связаться
ГУРУПРАКТИК
АЙТИ ПОД КЛЮЧ
Связаться

Maximum execution time exceeded: что делать, если PHP-скрипт превышает лимит времени

Maximum execution time exceeded: что делать, если PHP-скрипт превышает лимит времени

Ошибка «Maximum execution time exceeded» — одна из самых частых проблем на WordPress-сайтах. Она возникает, когда PHP-скрипт работает дольше допустимого лимита (по умолчанию 30 секунд). В этой статье разберём причины, диагностику и все способы исправления — от простых до продвинутых.

Что означает эта ошибка?

Когда вы видите сообщение:

Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/wp-content/plugins/some-plugin/class.php on line 42

Это значит, что PHP-процесс был принудительно остановлен после 30 секунд работы. Такое ограничение введено не просто так — оно защищает сервер от зависших скриптов и бесконечных циклов. Но когда лимит мешает нормальной работе сайта, его нужно увеличивать или устранять причину замедления.

Основные причины

  1. Тяжёлый плагин — импорт/экспорт данных, обработка изображений, генерация отчётов
  2. Проблемы с хостингом — медленный CPU, нехватка памяти, перегруженный соседний сайт на shared-хостинге
  3. Внешние запросы — плагин пытается достучаться до недоступного API или долго ждёт ответа
  4. Утечка памяти — скрипт обрабатывает данные, но не освобождает память (например, при импорте CSV на 100 000 строк)
  5. Медленные SQL-запросы — отсутствие индексов в таблицах wp_options, wp_postmeta

Как диагностировать

Включите WP_DEBUG

Откройте wp-config.php и убедитесь, что там есть:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

После этого ошибки будут писаться в файл /wp-content/debug.log. Прочитайте его — там будет точная строка и файл, где произошёл сбой.

Проверьте error_log сервера

Если WP_DEBUG не помог, посмотрите системный лог:

tail -100 /var/log/php_errors.log
# или, если используете Apache:
tail -100 /var/log/apache2/error.log

Способы исправления

Способ 1. Увеличить max_execution_time в wp-config.php (простой)

Добавьте в wp-config.php перед строкой «That’s all, stop editing!»:

set_time_limit(120);

Или глобально для всего сайта:

define('WP_MAX_EXECUTION_TIME', 120);

Способ 2. Через php.ini (надёжный)

Найдите путь к PHP-конфигу:

php --ini
# или создайте info.php с <?php phpinfo(); ?>

В файле php.ini найдите и измените:

max_execution_time = 120
max_input_time = 120
memory_limit = 256M

После изменений перезапустите веб-сервер:

sudo systemctl restart apache2   # для Apache
sudo systemctl restart nginx     # для Nginx + PHP-FPM
sudo systemctl restart php8.1-fpm # для PHP-FPM

Способ 3. Через .htaccess (для shared-хостинга)

Если у вас нет доступа к php.ini, добавьте в .htaccess:

php_value max_execution_time 120
php_value max_input_time 120

Способ 4. Через пользовательский php.ini (cPanel, ISPmanager)

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

max_execution_time = 120
memory_limit = 256M

Способ 5. Для конкретного скрипта (точечное решение)

Если проблема только в одном месте (например, импорт товаров), добавьте в начало скрипта:

set_time_limit(0); // безлимитно для этого скрипта

Внимание: set_time_limit(0) отключает ограничение только для текущего скрипта. Используйте осторожно — скрипт с бесконечным циклом повесит сервер.

Что делать, если ничего не помогло

Проверьте плагины методом исключения

Поочерёдно отключайте плагины, начиная с тех, что работают с:

  • Импортом/экспортом данных (WP All Import, Yoast SEO Import)
  • Обработкой изображений (Smush, ShortPixel, Imagify)
  • Кэшированием (W3 Total Cache, WP Super Cache — их кроны бывают тяжёлыми)
  • Резервным копированием (UpdraftPlus, BackupBuddy)

После каждого отключения проверяйте, воспроизводится ли ошибка.

Оптимизируйте базу данных

  • Установите плагин WP-Optimize или Advanced Database Cleaner
  • Удалите ревизии записей (каждая правка сохраняет отдельную ревизию)
  • Очистите таблицу wp_options от транзиентов
  • Добавьте индексы на часто используемые столбцы в wp_postmeta

Перейдите на более быстрый хостинг

Это банально, но часто это единственное реальное решение. На дешёвых shared-хостингах CPU настолько слабый, что никакие настройки не спасут. Ориентиры для WordPress:

  • CPU: минимум 1 vCPU (лучше 2+)
  • RAM: от 512 MB для сайта-визитки, от 2 GB для интернет-магазина
  • Диск: SSD (NVMe желательно)

Профилактика

  1. Мониторинг: настройте оповещение, когда сайт начинает тормозить. Бесплатные варианты — UptimeRobot или Better Uptime.
  2. Крон: если проблема в WP-Cron, замените его на системный cron через DISABLE_WP_CRON и настройте wget -q -O /dev/null https://вашсайт.ru/wp-cron.php в crontab с интервалом каждые 5-15 минут.
  3. Лимиты: не ставьте max_execution_time больше 300 секунд «на всякий случай» — это маскирует проблему, а не решает её.
  4. Обновления: держите PHP, плагины и тему актуальными — в новых версиях часто оптимизируют производительность.

Краткий чек-лист

| Шаг | Действие |
|:—-|:———|
| 1 | Включите WP_DEBUG и найдите точный файл с ошибкой |
| 2 | Увеличьте лимит через wp-config.php или php.ini |
| 3 | Отключите подозрительные плагины по одному |
| 4 | Оптимизируйте базу данных (удалите ревизии и транзиенты) |
| 5 | Замените WP-Cron на системный cron |
| 6 | Проверьте нагрузку на хостинг и при необходимости смените тариф |

Вывод

Ошибка «Maximum execution time exceeded» — не приговор. Чаще всего она решается увеличением лимита времени в php.ini или wp-config.php. Но если проблема повторяется регулярно, ищите корень — тяжёлый плагин, неоптимизированную базу или слабый хостинг. Главное — не игнорировать её: если скрипты регулярно падают по таймауту, страдают не только посетители, но и SEO сайта.

Автор: Александр, технический специалист WordPress
Дата публикации: 5 июня 2026
Дата последнего обновления: 5 июня 2026