Почему PHP-скрипт превышает время выполнения и как это исправить. Пошаговая диагностика, изменение max_execution_time, поиск медленного кода и решения для WordPress, OpenCart, 1С-Битрикс и импорта данных.
Maximum execution time exceeded - ошибка PHP, которая означает, что скрипт превысил разрешённое время выполнения. Она может появиться при открытии страницы, импорте товаров, создании резервной копии, обновлении сайта или обработке изображений. Иногда достаточно увеличить лимит времени. Но если программа зависает или пытается выполнить слишком много работы за один запрос, изменение настройки только отложит ошибку.
В этом руководстве разберём, как найти причину, изменить max_execution_time и проверить результат. Инструкции подходят для WordPress, OpenCart, 1С-Битрикс и самописных сайтов на PHP.
Полное сообщение может выглядеть так:
Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/site/import.php on line 125Разберём его по частям:
Вместо 30 секунд могут быть указаны 60, 120, 300 или другое значение. Принцип тот же: скрипт не уложился в действующее ограничение.
Файл и строка в сообщении не всегда указывают на первопричину. Например, ошибка может появиться внутри библиотеки обработки изображений, а причина - в модуле, который передал ей тысячи фотографий за один запуск.
Число в ошибке не обязательно совпадает со временем ожидания в браузере. Способ подсчёта зависит от системы и сборки PHP. Кроме того, у веб-сервера и промежуточных сервисов есть собственные ограничения времени.
Не меняйте одновременно несколько настроек: иначе будет трудно понять, какое изменение помогло.
Скрипт пытается сразу импортировать весь каталог, пересчитать цены, создать миниатюры для всех изображений или сформировать большой отчёт. Даже исправный код может не успеть закончить такую задачу в отведённое время.
Что помогает: обработка небольшими порциями, сохранение прогресса и продолжение со следующей позиции.
Программа снова и снова выполняет одну операцию: не переходит к следующей записи, повторяет неудачный запрос без ограничения или запускает сама себя через обработчик события.
Что помогает: исправление условия завершения, ограничение количества повторных попыток и проверка логики обработки. Увеличение времени здесь не устраняет причину.
Дополнение может многократно обрабатывать одинаковые данные, перестраивать большой список при каждом открытии страницы или выполнять тяжёлую операцию там, где достаточно взять готовый результат из кеша.
Что помогает: определение конкретного дополнения, проверка его настроек и исправление проблемного участка. Само по себе большое количество плагинов ещё не доказывает причину: перегрузить сайт может и один модуль.
Фотографии большого разрешения, массовая конвертация и создание архивов требуют вычислительных ресурсов. Если всё выполняется за один запуск, скрипт может упереться в ограничение времени.
Что помогает: разумные размеры исходных изображений, пакетная обработка и отдельные фоновые задания.
Многочисленные обращения к базе, повторные запросы к API и обработка больших ответов увеличивают длительность задачи. Но ожидание SQL-запроса или ответа API не всегда напрямую расходует именно лимит max_execution_time: это зависит от среды выполнения. Нужно проверять также тайм-ауты соединений и серверные журналы.
Что помогает: сокращение числа запросов, анализ медленных операций, отдельные ограничения времени для внешних обращений и ограничение повторов.
Если импорт, резервное копирование и обработка изображений запускаются одновременно, они конкурируют за ресурсы. Дополнительная проблема возникает, когда новая копия задания стартует раньше, чем завершилась предыдущая.
Что помогает: разнести тяжёлые задачи по времени и запретить одновременное выполнение нескольких экземпляров одного задания.
Проверьте, возникает ли ошибка на всех страницах или только при конкретной операции:
На виртуальном хостинге журнал обычно доступен в панели управления. Название раздела может отличаться: «Логи», «Журнал ошибок», «Ошибки PHP». Универсального пути к файлу нет.
Найдите Maximum execution time и посмотрите соседние записи. Зафиксируйте путь к файлу, номер строки и время. Если указан файл ядра CMS, не редактируйте его наугад: сначала выясните, какое дополнение или действие привело к его выполнению.
Если панель хостинга не показывает фактическое значение, можно временно создать в корне нужного сайта файл с непредсказуемым названием, например check-time-a7c4.php, и поместить в него:
<?php echo (int) ini_get('max_execution_time');Откройте файл по адресу своего сайта. Число 30 означает лимит 30 секунд, 120 - 120 секунд. Значение 0 означает отсутствие ограничения со стороны этой настройки PHP, но не отменяет другие ограничения сервера. После проверки удалите файл.
Важно: отдельный проверочный файл показывает начальную настройку для своего запроса. CMS или модуль могут изменить её позже. Если результат не совпадает с числом в ошибке, разработчику нужно проверить значение непосредственно перед проблемной операцией.
Для импорта подготовьте небольшой тестовый файл. Для обработки изображений выберите несколько файлов. Если маленькая порция проходит, а большая падает, это указывает на зависимость от объёма данных, но ещё не исключает ошибку в конкретной записи.
Если выполнение каждый раз обрывается на одном товаре или изображении, отдельно проверьте эту запись. Если точка остановки меняется с размером порции, изучайте производительность и ограничения.
Если у вас есть доступ к PHP-коду, добавьте временные записи в журнал до и после проблемного участка. Так можно выяснить, где задерживается выполнение: при чтении файла, обработке товаров или создании изображений.
Для PHP 7.3 и новее перед проверяемым участком добавьте:
$stageStarted = hrtime(true); error_log('Import stage: start');Сразу после этого участка добавьте:
error_log('Import stage: seconds=' . round((hrtime(true) - $stageStarted) / 1000000000, 3));Это две вставки вокруг существующего кода, а не самостоятельная программа. Замените подпись Import stage на понятное название проверяемого этапа. Код добавляется в PHP-файл, а не в редактор текста страницы.
Если в журнале есть начало, но нет окончания, проверьте сообщения между этими записями. Причиной может быть тайм-аут, другая фатальная ошибка или досрочное завершение программы. При одновременных запусках добавляйте к сообщениям идентификатор задания, чтобы не перепутать записи.
Измерение показывает прошедшее время, включая ожидание внутри операции. Оно может отличаться от времени, которое PHP учитывает для своего ограничения. Не записывайте в журнал пароли, токены и персональные данные. После диагностики удалите временные вставки.
Выберите один способ, который поддерживает ваш хостинг. Для диагностической проверки можно установить 120 секунд. Это пример, а не универсальное значение для любого сайта. Для обычной страницы ожидание даже в десятки секунд уже требует отдельного разбора.
max_execution_time.Если параметр недоступен, уточните у поддержки, каким способом разрешено менять его для вашего сайта.
Если у вас есть доступ к используемому файлу конфигурации PHP, измените существующую настройку:
max_execution_time = 120Редактировать нужно конфигурацию нужной версии PHP и нужного обработчика. Файл для командной строки может отличаться от файла для сайта. Простое создание php.ini рядом с index.php работает не на каждом хостинге.
После изменения основной конфигурации может понадобиться перезагрузка соответствующей службы PHP или веб-сервера. На управляемом хостинге это выполняется через панель либо поддержку.
Для CGI/FastCGI, включая распространённые конфигурации PHP-FPM, может использоваться файл .user.ini. Его обработка должна быть разрешена на сервере.
.user.ini. Если его нет и хостинг поддерживает этот способ, создайте файл.max_execution_time = 120Файл может перечитываться с задержкой: стандартный интервал составляет пять минут, но хостинг вправе изменить его. Подождите и снова проверьте значение. Если настройка не применяется, не добавляйте новые копии файла в случайные папки - уточните конфигурацию сайта.
Этот вариант подходит, когда PHP работает как модуль Apache и сервер разрешает такие директивы. Наличие Apache само по себе ещё не означает, что способ доступен.
После сохранения копии .htaccess можно добавить:
php_value max_execution_time 120Если сразу появилась ошибка 500, удалите добавленную строку или восстановите копию файла. Для типичной конфигурации с PHP-FPM используйте панель хостинга или поддерживаемый файл .user.ini. Сам Nginx файл .htaccess не обрабатывает.
Разработчик может задать ограничение перед длительной операцией:
set_time_limit(120);Другой вариант:
ini_set('max_execution_time', '120');Обычно достаточно одного подхода. Вызов set_time_limit() начинает отсчёт заново с момента вызова. Не нужно бездумно повторять его в каждом проходе цикла: так можно надолго сохранить зависшую задачу.
Эти строки помещают внутрь PHP-кода до проблемной операции. Ограничения хостинга могут запрещать изменение параметров или использование функции. После добавления проверьте журнал и фактическое значение настройки.
Начните с действия, которое вызывает ошибку: обновление, импорт, резервное копирование, открытие редактора или работа конкретного плагина.
wp-content/plugins/, проверьте соответствующий плагин. Если указан wp-includes, это ещё не доказывает неисправность ядра.Если админка недоступна, подозрительный плагин можно временно отключить переименованием его папки через файловый менеджер. Сначала сохраните исходное название. Учитывайте, что связанные функции сайта временно перестанут работать.
В файле wp-config.php до подключения wp-settings.php задайте следующие значения. Если константы уже присутствуют, измените их, а не создавайте дубли:
define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);Повторите действие и проверьте wp-content/debug.log. Запись требует возможности создавать и изменять файл. Закройте доступ к журналу из браузера или настройте запись вне публичной папки. После диагностики отключите отладку и удалите ненужный журнал.
Да, если настройки сервера это разрешают: строку set_time_limit(120); размещают внутри PHP-кода до подключения wp-settings.php. Но изменение может затронуть разные запросы сайта, поэтому для постоянного решения лучше исправить конкретную тяжёлую операцию.
Константы WP_MEMORY_LIMIT и WP_MAX_MEMORY_LIMIT относятся к памяти. Увеличивать их вместо времени выполнения бессмысленно, если проблема именно в тайм-ауте.
В интернет-магазине начните с проверки импорта прайс-листа, обмена с учётной системой, массового изменения товаров, обработки изображений и формирования товарного фида.
Расположение журнала OpenCart зависит от версии и настройки каталога хранения. Если ошибка не попала в журнал магазина, проверьте журнал PHP на хостинге.
Для самописного сайта подход такой же: определите точку запуска, запишите этапы выполнения и найдите участок, который занимает слишком много времени. Не вносите одинаковые изменения сразу во все входные файлы CMS.
Если ошибка появляется в Битрикс, сначала определите операцию: обмен с 1С, импорт каталога, переиндексация поиска, резервное копирование или выполнение собственного обработчика. От этого зависит, какую настройку проверять.
Если сбой возникает без обмена с 1С, проверьте компоненты и обработчики событий, которые выполняются при проблемном действии. Например, сохранение товара может запускать дополнительную обработку, которая снова сохраняет тот же товар и повторно вызывает обработчик.
Путь внутри bitrix/modules/ показывает место остановки, но сам по себе не доказывает ошибку ядра. Не редактируйте системный файл только потому, что он указан в сообщении. Сначала выясните, какой код вызвал эту операцию, и воспроизведите проблему на тестовой копии.
Для длительных задач надёжнее ограничивать объём одного шага, чем постоянно увеличивать время одного запроса. Например, обработать небольшую группу товаров, сохранить прогресс и перейти к следующей.
Размер порции подбирают по реальной задаче. Импорт 100 простых записей и импорт 100 товаров со скачиванием фотографий могут иметь совершенно разную нагрузку.
После сбоя резервного копирования не считайте полученный архив исправным только потому, что файл существует. Проверьте статус задания, содержимое архива и возможность восстановления на тестовой площадке.
Если приложение поддерживает консольный запуск, длительную задачу можно выполнять через CLI, в том числе по расписанию cron. Это убирает зависимость от ожидания ответа браузером, но не исправляет ошибку алгоритма.
Пример для подготовленного консольного скрипта с ограничением 300 секунд:
php -d max_execution_time=300 /path/to/import.phpЗамените путь на настоящий. Уточните, какую версию PHP запускает команда php. В CLI могут использоваться другие настройки и права доступа. Обычный веб-скрипт нельзя считать готовым к консольному запуску без проверки.
Вызов URL сайта через cron остаётся HTTP-запросом: ограничения веб-сервера при этом сохраняются.
Проверьте домен, версию PHP, каталог и способ запуска. Изменение настроек CLI не обязательно изменяет настройки сайта. Отдельный поддомен также может использовать собственную конфигурацию.
В коде может быть собственный вызов set_time_limit() или ini_set(). Администратор сервера также может закрепить значение, которое нельзя изменить из приложения. Сравните настройку до запуска CMS и непосредственно перед проблемным действием.
У PHP-FPM существует отдельная настройка request_terminate_timeout. Она может завершить обработку запроса независимо от ожидаемого вами поведения max_execution_time. Её проверяют в конфигурации пула PHP-FPM или через поддержку хостинга.
Если вместо PHP-ошибки появилась 504 Gateway Timeout, нужно проверить всю цепочку обработки запроса. У Nginx параметр fastcgi_read_timeout ограничивает ожидание между последовательными чтениями ответа от FastCGI, а не обязательно полную длительность операции. При проксировании может действовать другой тайм-аут.
Не повышайте все ограничения подряд. Сначала по журналам определите, какой компонент прервал запрос. Обрыв ответа в браузере также не всегда означает, что обработка на сервере уже остановилась.
Если после изменения ошибка стала содержать 120 секунд вместо 30, настройка, вероятно, применилась, но задача всё равно не завершилась. Проверяйте прогресс: продолжается ли полезная обработка или повторяется один и тот же участок.
Для сложных случаев разработчик может использовать профилирование, журнал длительности этапов и slowlog PHP-FPM - журнал, который помогает увидеть, где задерживается выполнение запроса.
Если для диагностики лимит поднимали с запасом, после оптимизации установите обоснованное значение. Исчезновение сообщения само по себе ещё не доказывает, что сайт работает нормально.
Проверьте журнал и действие, вызвавшее ошибку. Если это большая разовая операция, уменьшите объём одного шага или проверьте увеличение лимита до 120 секунд. Если зависает обычная страница, ищите проблемный код: увеличение времени не сделает её быстрее.
Время ожидания по часам и время, которое PHP учитывает для ограничения, могут различаться. На многих Linux-серверах ожидание базы данных, сетевых операций и другие внешние задержки не учитываются так же, как выполнение PHP-кода. На Windows и в некоторых сборках PHP поведение отличается.
Кроме того, вызовы set_time_limit() начинают отсчёт заново. Проверьте действующее значение перед проблемным участком и найдите в коде повторные изменения лимита. Само расхождение между 120 секундами в сообщении и 15 минутами по часам ещё не доказывает неисправность сервера.
Это отключает ограничение времени со стороны данной настройки PHP. Для публичного сайта использовать такое значение как универсальное исправление не стоит: зависший скрипт может долго занимать ресурсы. Другие серверные ограничения при этом сохраняются.
Обычно нет. Этот параметр относится к разбору входных данных запроса, а max_execution_time - к выполнению скрипта. Менять max_input_time следует при подтверждённой проблеме на соответствующем этапе.
Оно решает другую задачу - ограничение доступной PHP памяти. Сообщение Allowed memory size exhausted требует отдельной диагностики. Ошибки памяти и времени могут встречаться в одной тяжёлой операции, но это разные ограничения.
Именно сообщение PHP Maximum execution time exceeded формируется на сервере. Очистка кеша браузера и замена интернет-подключения не исправляют серверный код или настройку времени.
На рабочем сайте технические ошибки следует записывать в журнал, а не показывать посетителям. Но отключение их отображения не исправляет сбой: скрипт по-прежнему может прерываться, а операция - оставаться незавершённой.
Нет. Сначала проверьте задачу, настройки и реальное использование ресурсов. Переезд может помочь при подтверждённой нехватке мощности или неподходящих ограничениях тарифа, но не исправит бесконечный цикл.
Передайте домен, время ошибки с часовым поясом, полный текст сообщения, описание действия и действующее значение max_execution_time. Укажите, как запускается задача: через браузер, HTTP-запрос по расписанию или CLI. Попросите проверить применённую конфигурацию PHP и серверные тайм-ауты.
Если ошибка возвращается, помогу найти причину: проверю журналы, настройки PHP, работу плагинов и модулей, импорт и фоновые задания. При необходимости доработаю обработку данных, чтобы задача выполнялась порциями и могла продолжаться после прерывания. Напишите мне через форму обратной связи на сайте, на почту или в мессенджер, приложите текст ошибки и опишите, после какого действия она появляется. Рабочие вопросы обсуждаю письменно.
Переработана структура каталога интернет-магазина на OcStore 1.5.6.4: карточки товаров получили постоянные URL и стабильные хлебные крошки, старые адреса перенаправляются через 301 Redirect, а отдельные товары теперь можно выводить в плитках категорий вместе с подкатегориями.
Переработал страницы онлайн-оплаты туров: убрал устаревшие даты и служебные элементы, сделал кнопку оплаты заметнее и создал единый шаблон для всех направлений.
Пришлите ссылку на сайт и кратко опишите задачу — я посмотрю и предложу следующий шаг.