Как исправить утечку памяти в PHP

Было бы полезно взглянуть на код, но если вы хотите отладить его самостоятельно, взгляните на Xdebug , это поможет профилировать ваше приложение.

Конечно, в зависимости от того, что вы делаете, возможно, он накапливает некоторую память, хотя 132 МБ кажутся уже высокими для 2500 записей. Конечно, вы можете настроить лимит памяти в php.ini, если нужно.

Насколько велик CSV-файл, который вы читаете? И какие объекты и какую обработку вы с ним делаете?

Если вы действительно подозреваете, что в вашем скрипте есть только одна или две утечки памяти, которые вызывают его сбой, вам следует предпринять следующие шаги:

• Измените memory_limit на что-нибудь маленькое, например 500 КБ
• Закомментируйте все шаги обработки, кроме одного, которые применяются к каждой строке.
• Запустите ограниченную обработку всего файла CSV и посмотрите, можно ли ее завершить.
• Постепенно добавляйте больше шагов и наблюдайте, не вырастет ли использование памяти.

Пример:

ini_set('memory_limit', 1024 * 500);
$fp = fopen("test.csv", 'r');
while($row = fgetcsv($fp)) {
    validate_row($row);         // step 1: validate
    // add these back in one by one and keep an eye on memory usage
    //calculate_fizz($row);     // step 2: fizz
    //calculate_buzz($row);     // step 3: buzz
    //triangulate($row);        // step 4: triangulate
}
echo "Memory used: ", memory_get_peak_usage(), "\n";

В худшем случае все этапы обработки умеренно неэффективны, и вам нужно будет их все оптимизировать.

Это зависит от того, как вы очищаете переменные после того, как закончите с ними.

Похоже, вы закончили с записью, но вы все еще где-то храните информацию. Используйте unset (), чтобы очистить переменные, если есть сомнения.

Пожалуйста, предоставьте минимальный образец воспроизводящего кода, чтобы увидеть, куда уходит вся эта память, если это не помогает.

Кстати, создание наименьшего образца кода, который воспроизведет проблему, - отличный метод отладки, потому что он заставляет вас снова пройти код с осторожностью.

вы можете попробовать локальную установку php5.3 и позвонить по адресу http://www.php.net/manual/en/function.gc-collect-cycles.php.

gc_collect_cycles - Принудительная сборка любых существующих циклов мусора

если ситуация улучшится, вы, по крайней мере, подтвердили (одну из) проблему (ы).

Как ты читаешь файл? Если вы используете fread / filegetcontents или другие подобные функции, тогда вы собираетесь использовать весь размер файла (или то, сколько вы загружаете с помощью fread) в памяти, поскольку весь файл загружается во время вызова. Однако, если вы используете fgetcsv, если вы будете читать только одну строку за раз в зависимости от длины строки, это может быть значительно легче на вашей памяти.

Также убедитесь, что вы повторно используете как можно больше переменных в каждом цикле. Убедитесь, что в них нет массивов с большими объемами данных.

В качестве последнего примечания также убедитесь, что вы открываете файл перед циклом, а затем закрываете его после слов:

$fh = fopen(...);
while(true)
{
//...
}
fclose($fh);

Вы действительно не хотите этого делать:

while(true)
{
$fh = fopen(...);
//...
fclose($fh);
}

И, как говорили другие, будет сложно сказать, не увидев кода.

Трудно сказать причину, не видя кода. Однако типичной проблемой являются рекурсивные ссылки, т.е. объект A указывает на объект B и наоборот, что может привести к поломке GC.

Я не знаю, как вы сейчас обрабатываете файл, но вы можете попытаться прочитать файл только по одной строке за раз. Если вы прочитаете весь файл сразу, он может занять больше памяти.

На самом деле это одна из причин, по которой я часто предпочитаю Python для задач пакетной обработки.

Можете ли вы изменить свой memory_limit в своем php.ini?

Кроме того, может ли выполнение unset ($ var) для переменных освободить некоторую память? Может ли $ var = null помочь?

См. Также этот вопрос: Что лучше при освобождении памяти с PHP: unset () или $ var = null

У меня была такая же проблема, и это также было связано с профилированием базы данных (Zend_Db_Profiler_Firebug). В моем случае утечка составляла 1 МБ в минуту. этот сценарий должен был работать несколько дней, поэтому он вылетал через несколько часов.