Если выгрузка, каталог или отчёт обрывается с Allowed memory size exhausted, сначала нужно найти этап роста памяти и проверить действующий лимит PHP. Одно повышение memory_limit не объясняет причину сбоя. Руководителю проекта нужен воспроизводимый сценарий и сравнение замеров до и после исправления, чтобы принять работу по результату.
Начните с трёх безопасных действий:
- Запишите время сбоя, действие пользователя и объём входных данных. Для выгрузки важны период, фильтры и количество записей, а не только адрес страницы.
- Попросите разработчика сопоставить событие с журналом PHP. Для обсуждения оставьте текст ошибки и числовые значения; удалите контакты, токены и внутренние пути.
- Согласуйте проверку на изолированной копии. Не запускайте тяжёлую операцию многократно на рабочем сайте и не повторяйте платёж или импорт, пока не выяснено, что уже сохранилось.
Что означает ошибка и чего она не доказывает
memory_limit ограничивает выделение памяти PHP-скриптом. Ошибка означает, что выполнение столкнулось с этим ограничением; она сама по себе не доказывает утечку, нехватку памяти всего сервера или необходимость сменить хостинг. Детали обработки превышения зависят от версии PHP, поэтому фиксируют точную установленную версию и её настройки.
В сообщении обычно указаны разрешённый объём и размер очередного выделения. Последнее число не показывает всю потребность операции: небольшой дополнительный блок может оказаться последним после большого накопления данных. Файл и строка показывают место обнаружения сбоя, а память могла быть занята раньше.
Последствия зависят от сценария. Отчёт может остаться неполным, а импорт — успеть записать часть данных. До повторного запуска нужна проверка результата: наличие файла или код ответа сами по себе не подтверждают полноту операции.
Как подготовить сравнимый прогон на копии
Выберите один сценарий: например, выгрузку за фиксированный период. Подготовьте обезличенные данные той же структуры и объёма. У копии должны быть отдельные база, очередь и файловое хранилище; отправку писем, оплату и внешние обмены отключают либо переводят в согласованный тестовый режим.
Зафиксируйте версию PHP, набор расширений, версию приложения, состояние кеша, фильтры и число записей. Разработчик проверяет ini_get('memory_limit') именно в том способе запуска, где происходит сбой. Значение из командной строки не следует автоматически переносить на запрос через сайт: конфигурации могут различаться.
Измерения добавляют в закрытую диагностику копии. Не размещайте общедоступный phpinfo(), дамп объектов или полный журнал запросов. Если сначала нужно зафиксировать ожидаемое поведение старого кода, пригодится разбор первых тестов PHP-проекта.
Четыре гипотезы: что сравнить и какой вывод допустим
Лимит отличается от ожидаемого. После переноса или изменения окружения один и тот же сценарий может работать с другими настройками. Сопоставьте действующие значения в проблемном и контрольном запуске. Если различие подтвердилось, согласуйте конфигурацию с доступными ресурсами. Успех при большем лимите доказывает только достаточность этого лимита для проверенного прогона.
В PHP загружается слишком много строк. Резкий рост после получения данных — повод проверить число строк, набор полей и загрузку связанных записей. В документации PHP отмечено, что fetchAll() собирает оставшийся результат в массив и большая выборка требует значительных ресурсов. Возможные решения — отбор в базе и обработка порциями. Их проверяют на полноту данных, включая границы порций.
Объекты или результаты накапливаются в цикле. Сравните память после нескольких одинаковых порций. Если текущий расход растёт, проверьте коллекции результатов, ссылки на обработанные объекты и отладочные накопители. Нужен конкретный удерживающий объект или структура, а не диагноз по одному графику. Сборщик мусора не освободит данные, которые приложение продолжает использовать.
Пик появляется при сборке ответа. Если строки уже прочитаны, а скачок возникает при преобразовании в JSON, формировании файла или шаблона, исследуйте этот этап отдельно. Большой исходный набор и готовый результат могут одновременно занимать память. Потоковая запись или разбиение работы полезны только после проверки формата, полноты и поведения при прерывании.
Простая замена
fetchAll()на построчный цикл не гарантирует ограниченный расход памяти. Драйвер базы может буферизовать результат, а код — снова складывать строки в общий массив. Режим чтения выбирают по документации используемого драйвера и проверяют замерами.
Таблица памяти: где произошёл скачок
Разработчик ставит контрольные точки после запуска приложения, чтения данных, преобразования и записи результата. В документации PHP memory_get_usage() описывает текущую память, учитываемую менеджером PHP, а memory_get_peak_usage() — достигнутый максимум. Аргумент true включает зарезервированные менеджером блоки. Эти показатели не равны полной памяти процесса в операционной системе.
Ниже учебная иллюстрация двух прогонов на одинаковых данных. Все числа условные, это не результат клиентского проекта и не обещание снижения расхода. В ячейке указаны текущая память и накопленный пик; обе функции вызваны с true. МиБ — единица, равная 1 048 576 байтам.
| Контрольная точка | До изменения, текущая / пик, МиБ | После изменения, текущая / пик, МиБ |
|---|---|---|
| Приложение запущено | 20 / 20 | 20 / 20 |
| Данные прочитаны | 82 / 82 | 32 / 34 |
| Результат подготовлен | 110 / 114 | 36 / 42 |
| Файл записан | 110 / 114 | 36 / 42 |
Такая таблица помогает выбрать участок для дальнейшей проверки. Она не устанавливает причину автоматически: снижение пика бессмысленно, если новая версия пропускает часть записей.
Без сброса счётчика пик накопительный: он не обязан уменьшаться на следующем этапе. Разность соседних пиков также не равна расходу отдельного этапа. Чтобы локализовать короткий всплеск, нужны дополнительные точки или профилирование на копии. Сохранение зарезервированной памяти после освобождения объектов само по себе не доказывает утечку.
Если исходный сценарий падает раньше последней точки, это фиксируют как обрыв. Отсутствующее измерение не заменяют нулём. Для завершившегося уменьшенного примера отдельно указывают объём данных: его нельзя выдавать за успешный прогон исходной задачи.
Как принять исправление и наблюдать после релиза
До изменения согласуйте проверяемые условия приёмки:
- Исходный проблемный объём обрабатывается полностью: сходятся количество записей, состав результата и контрольные итоги.
- Повторный прогон использует те же данные, настройки и состояние кеша. Замеры сняты тем же способом.
- На заранее согласованном большем объёме расход остаётся в допустимом бюджете; если работа разбита на порции, внутри одного запуска нет необъяснённого накопления от порции к порции.
- Проверены соседние сценарии: права доступа, сохранение данных, повтор после прерывания и отсутствие дублей.
- После выпуска наблюдают проблемную операцию и ошибки PHP в согласованном окне, которое включает её реальный запуск. Ответственный и условия отката известны заранее.
Бюджет памяти выбирают с учётом параллельных запросов и других процессов. Универсального безопасного значения для всех сайтов нет. Отключение лимита значением -1 не считается исправлением; повышение без проверки общей нагрузки может перенести проблему на весь сервер.
Когда достаточно своей команды, а когда нужна помощь
Если разработчик может изолировать сценарий, найти этап роста и показать полный результат на одинаковых данных, диагностику можно провести своими силами. Владельцу достаточно проверить условия сравнения и критерии приёмки — разбирать каждую строку кода не требуется.
Помощь нужна, когда неизвестно, где меняется лимит, память растёт в чужом коде или безопасную копию не удаётся подготовить. В составе поддержки сайта OpenStart команда разбирает ошибки и согласует необходимые доработки. Для такого обращения полезны симптом, время, версия PHP, объём операции и обезличенный пример; доступы на первом шаге не нужны.
Сначала уточняют границы диагностики и ожидаемый результат, затем согласуют состав и оценку работ. Это позволяет обсуждать конкретную проверку и исправление без обещания заранее известной причины.