Выявить утечку памяти

@JamesHound · Регистрация: 27.08.2013

Студворк — интернет-сервис помощи студентам

Здравствуйте. Написал парсер с библиотекой для парсинга simple_html_dom. После длительного парсинга видно, что память переполняется. Можно ли как то узнать, в каком месте идет переполнение памяти ? Профайлер может

@Tatikoma · 24.08.2014, 17:57

Пробовал ловить утечки памяти в большом проекте - дело совершенно неблагодарное.

Первое что я сделал - попробовал повтыкать везде memory_get_usage, - ничего толком не получилось.

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

Потом пробовал различные профайлеры - они в принципе ничего не дали, кроме красивой картинки..

Еще помню пробовал играться с версией PHP, накатывать различные патчи.. ничего особо не помогло.. =)

Затем я вернулся к первому способу и таки нашел утечку памяти.. в PECL'овом расширении amqp для PHP..

Соответственно не могу ничего конкретного посоветовать, - утечки памяти ловить сложнее других ошибок и конкретного рецепта как с ними бороться - не существует.

@asmprog · 25.08.2014, 13:27

simple_html_dom - это PHP библиотека, поэтому говорить об "утечке" памяти тут не приходится. PHP устроен так, что для каждой сессии(клиентского запроса от веб-сервера или другого SAPI) образует отдельный блок памяти(ограниченный сверху настройками), который привязан к этой сессии. Превышение лимита дает всем знакомое сообщение, в котором как раз и указано - где именно осуществляют попытку выделить очередной кусок из блока, который становится фатальным. Важно понимать, что не только PHP код может вызвать превышение лимита - каждый include`нутый файл представляет собой байт-код(+к использованной памяти), служебные структуры, описывающие контекст этого байт-кода(+к использованной памяти) и много чего еще(даже отложенное создание классов на деле реализовано как дублирование записи в соответствующей hash-таблице).

По-сему:
1. unset переменных, которые далее по коду не нужны
2. повышение лимита в настройках

@V@D!k · 25.08.2014, 14:46

по-моему сам simple_html_dom довольно кривоватый, пользовался им, возникали такие же проблемы при больших объемах, поэтому если не слишком сложный парсинг, лучше использовать регулярки, также посоветовал бы вам обратить внимание на PHPQuery

@Tatikoma · 25.08.2014, 16:43

asmprog, речь очевидно идет о CLI-демоне, ваше сообщение немного о другом.

Сообщение от asmprog

simple_html_dom - это PHP библиотека, поэтому говорить об "утечке" памяти тут не приходится

Глупости, утчеки памяти могут быть где угодно. Как я уже писал выше - лично находил утечку в пхп'шной либе.

Сообщение от asmprog

1. unset переменных, которые далее по коду не нужны

Глупость, unset - пережиток PHP4, в подавляющем большинстве случаев он не нужен - gc сейчас и сам отлично удаляет ненужные переменные.

Сообщение от asmprog

2. повышение лимита в настройках

Чем это поможет? - Ну сдохнет парсер не через 2 часа, а через 4, через день?

Сообщение от V@D!k

по-моему сам simple_html_dom довольно кривоватый

И это никак не мешает найти строчку вызов которой приводит к утечке памяти, а потом написать баг-репорт разработчикам, если это их косяк =) Хотя маловероятно, что косяк там, т.к.:

PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<?php
$string = <<<XML
<?xml version='1.0'?> 
<document>
 <title>Forty What?</title>
 <from>Joe</from>
 <to>Jane</to>
 <body>
  I know that's the answer -- but what's the question?
 </body>
</document>
XML;
 
for($i = 0; $i < 10; $i ++){
        $xml = simplexml_load_string($string);
        print memory_get_usage() . PHP_EOL;
}

Судя по этому - с либой все нормально, возможно проблема есть на специфических XML'ках. Попробовать скормить в этот скрипт те xml'ки которые вызывают проблему - посмотреть.

@V@D!k · 25.08.2014, 17:39

увидел интересную ссылку, почитайте, может быть вам поможет
p.s. самое главное в конце

@asmprog · 25.08.2014, 17:50

Сообщение от Tatikoma

asmprog, речь очевидно идет о CLI-демоне, ваше сообщение немного о другом.

CLI-демон(Command Line Interface?) =) Глупости вашей нет предела? =) Или может быть все таки CGI(FastCGI)-демон? Да будет Вам известно, что все что "компилирует" PHP код называется SAPI и поддерживает общий интерфейс, в рамках которого требуется вызывать функции движка PHP php_request_startup/php_request_shutdown для обозначения "границ" запроса клиента перед непосредственной компиляцией PHP кода.

Сообщение от Tatikoma

Глупости, утчеки памяти могут быть где угодно. Как я уже писал выше - лично находил утечку в пхп'шной либе.

В PHP extension утечка быть может, а "где угодно" нет!

Сообщение от Tatikoma

Глупость, unset - пережиток PHP4, в подавляющем большинстве случаев он не нужен - gc сейчас и сам отлично удаляет ненужные переменные.

unset вызывает деструктор(dtor) переменной, т.е. разрушается экземпляр класса, массив(и все что в массиве), память выделенная под строку освобождается. А gc вызывает цикл сборки мусора как раз при завершении сессии.

Сообщение от Tatikoma

Чем это поможет? - Ну сдохнет парсер не через 2 часа, а через 4, через день?

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

P.S. не советую Вам, Tatikoma, пороть хрень с умным видом(не в лучшем свете себя выставляете), а уж тем более спорить со мной о внутренностях интерпретатора(движка Zend в частности), поскольку я уже года 3 копаюсь в исходниках, а вот Вы в элементарных вещах умудрились запутаться.

@Tatikoma · 25.08.2014, 21:54

asmprog, вы зря употребляете слово "компиляция" к PHP-коду, т.к. ни трансляция в байт-код, не исполнение байт-кода компиляцией по-факту не является.

Сообщение от asmprog

В PHP extension утечка быть может, а "где угодно" нет!

Под "где угодно" подразумеваются лишь места, где она может быть. Например в ядре ОС =)

Сообщение от asmprog

unset вызывает деструктор(dtor) переменной, т.е. разрушается экземпляр класса, массив(и все что в массиве), память выделенная под строку освобождается. А gc вызывает цикл сборки мусора как раз при завершении сессии.

PHP
1
2
3
4
function test(){
    $x = 'abc';
}
test();

Т.е. место под переменную $x - останется занятым? - Не-не-не, неиспользуемые переменные PHP сам удаляет без подсказок.

Сообщение от asmprog

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

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

Сообщение от asmprog

P.S. не советую Вам, Tatikoma, пороть хрень с умным видом(не в лучшем свете себя выставляете), а уж тем более спорить со мной о внутренностях интерпретатора(движка Zend в частности), поскольку я уже года 3 копаюсь в исходниках, а вот Вы в элементарных вещах умудрились запутаться.

Переходите на PHP5, там более интересные исходники, чем в вашей версии =)

PS: Даже не нашелся что ответить на ваш выпад в послесловии. Предлагаю воздержаться от перехода на личности и сохранить нетралитет дискуссии, т.к. сливание обсуждения в холивар - плохая привычка.

@asmprog · 26.08.2014, 18:37

Сообщение от Tatikoma

asmprog, вы зря употребляете слово "компиляция" к PHP-коду, т.к. ни трансляция в байт-код, не исполнение байт-кода компиляцией по-факту не является.

Сообщение от Tatikoma

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

Перечитал, вот полная цитата(Вы в отдельном мире живете, где "длительный парсинг" равнозначен "нескольким итерациям цикла"?):

Здравствуйте. Написал парсер с библиотекой для парсинга simple_html_dom. После длительного парсинга видно, что память переполняется. Можно ли как то узнать, в каком месте идет переполнение памяти ? Профайлер может

Сообщение от Tatikoma

Т.е. место под переменную $x - останется занятым? - Не-не-не, неиспользуемые переменные PHP сам удаляет без подсказок.

Для начала нужно понять что происходит.

PHP
1
2
3
4
function test(){
    $x = 'abc';
}
test();

Упрощенно:
1. Движок Zend регистрирует ф-цию test, разбирает ее на байт-код И ДОБАВЛЯЕТ В КОНЦЕ ОПКОД ZEND_RETURN
2. Переводит в байт-код вызов ф-ции test
3. Добавляет в конце безымянной ф-ции(точки входа) опкод ZEND_RETURN
4. Затирает опкод ZEND_DECLARE_FUNCTION опкодом ZEND_NOP(второй проход)

При вызове test, когда курсор виртуальной машины дойдет до опкода ZEND_RETURN в конце обработчика опкода(можно посмотреть в файле Zend\zend_vm_def.h) происходит передача управления хелперу

C
1
2
3
4
5
6
ZEND_VM_HANDLER(62, ZEND_RETURN, CONST|TMP|VAR|CV, ANY)
{ 
...
    FREE_OP1_IF_VAR();
    ZEND_VM_DISPATCH_TO_HELPER(zend_leave_helper);
}

В самом начале которого:

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
ZEND_VM_HELPER(zend_leave_helper, ANY, ANY)
{
...
    if (!EG(active_symbol_table)) {
        zval ***cv = EX(CVs);
        zval ***end = cv + EX(op_array)->last_var;
        while (cv != end) {
            if (*cv) {
                zval_ptr_dtor(*cv);
            }
            cv++;
        }
    }
}

вызывается деструктор всех ИНИЦИАЛИЗИРОВАННЫХ переменных.

zval_ptr_dtor при этом является макросом, указывающим на функцию

C
1
ZEND_API void _zval_ptr_dtor(zval **zval_ptr ZEND_FILE_LINE_DC)

внутри которой(ЕСЛИ счетчик ссылок на переменную будет == 0) вызывается(после уничтожения содержимого переменной - такая уж судьба, что переменная и содержимое не всегда хранятся вместе)

C
1
efree_rel(zv);

efree_rel в свою очередь ведет к

C
1
ZEND_API void _efree(void *ptr ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC)

, которая и "освобождает" переменную

C
1
_zend_mm_free_int(AG(mm_heap), ptr ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC);

А что будет если посмотреть код _zend_mm_free_int(Zend\zend_alloc.c)? Правильно, никакого освобождения памяти не происходит. Сначала берут блок, в котором хранится переменная. Помечают как освобожденный. Если след. блок свободен склеивают. Если предыдущий тоже свободен, склеивают предыдущий с текущим блоком. Уменьшают размер кучи текущей сессии. Но память системе не возвращается, чтобы всегда можно было выделить новый блок из свободных нужного размера.

-----------------------------------------------
---------------------НО-----------------------

Все это происходит КОГДА осуществляется выход из ф-ции. А вот то, о чем я говорил:

Сообщение от asmprog

1. unset переменных, которые далее по коду не нужны

Сообщение от Tatikoma

Переходите на PHP5, там более интересные исходники, чем в вашей версии =)

Весь C код, который я привел взят из исходников 5.3.8. Если этот пассаж выполнен в контексте

Сообщение от asmprog

поскольку я уже года 3 копаюсь в исходниках

, то выводы довольно сомнительные, поскольку PHP 5(из вики)

Пятая версия PHP была выпущена разработчиками 13 июля 2004 года.

Заключение: "утечек" памяти в PHP коде нет и быть не может. Могут существовать ошибки в коде движка Zend, интерпретатора, SAPI или расширения. Если хотите разобраться в менеджере памяти, Zend\zend_alloc.c в помощь.

@Tatikoma · 27.08.2014, 11:10

Сообщение от asmprog

"утечек" памяти в PHP коде нет и быть не может.

Исключительно если использовать термин утечки памяти как низкоуровневое понятие.

Случайно забытый элемент массива - чем не утечка памяти?

@asmprog · 27.08.2014, 11:39

Сообщение от Tatikoma

Случайно забытый элемент массива - чем не утечка памяти?

А я смотрю, Вы неугомоннный, так ведь? Сначала у Вас CLI может быть демоном. Потом сами для себя пост ТС переврали, в чем и меня пытались "убедить". Теперь "утечка памяти" у Вас носит не тот смысл, которым данный термин все НОРМАЛЬНЫЕ программисты наделяют. Что такое? Увидели новорега(меня) на форуме и ринулись ему свой авторитет доказывать? Да только новорег не такой простой оказался? Вот и приходится в спешном порядке цепляться к слову "компиляция" и утечкой памяти называть то, что ей не является, только бы сохранить "хорошую мину при плохой игре"?

@ads · 27.08.2014, 12:21

Не по теме:

Сообщение от asmprog

гупости вашей нет предела

Сообщение от asmprog

пороть хрень с умным видом

Сообщение от asmprog

поскольку я уже года 3 копаюсь

Сообщение от asmprog

Увидели новорега(меня) на форуме и ринулись ему свой авторитет доказывать

черт, авторитет! "я", "меня"... похоже слово авторитет вас волнует больше чем кого-то еще на этом форуме.

KOPOJI · 27.08.2014, 13:59

Мда.. Веселое обсуждение, нечего сказать. Столько слов об утечке памяти.. И что-то никто не предложил, к примеру, парсить xml по частям. Непонятно, чем тут поможет то, что будешь знать место "утечки"

Не по теме:

Сообщение от asmprog

поскольку я уже года 3 копаюсь в исходниках

Нафига..?

@V@D!k · 27.08.2014, 14:04

я ошибаюсь, или человек парсит контент с другого сайта а не с xml?

KOPOJI · 27.08.2014, 14:06

html, xml, какая разница.. А вот то, что с другого сайта - необязательно. Но если дело в этом, то, скорее всего, стоит сначала перекинуть контент к себе и парсить локально

@V@D!k · 27.08.2014, 14:11

наверное вы правы, но мы не узнаем истины, пока создатель темы не скажет, что он парсит

@Игорь[Igor] · 27.08.2014, 14:30

Не по теме:

Сообщение от KOPOJI

Нафига..?

Утечку ищет

KOPOJI · 27.08.2014, 14:31

Не по теме:

Игорь[Igor], :D

@Tatikoma · 27.08.2014, 18:10

Не по теме:

Сообщение от KOPOJI

Непонятно, чем тут поможет то, что будешь знать место "утечки"

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

Сообщение от asmprog

А я смотрю, Вы неугомоннный, так ведь? Сначала у Вас CLI может быть демоном. Потом сами для себя пост ТС переврали, в чем и меня пытались "убедить". Теперь "утечка памяти" у Вас носит не тот смысл, которым данный термин все НОРМАЛЬНЫЕ программисты наделяют. Что такое? Увидели новорега(меня) на форуме и ринулись ему свой авторитет доказывать? Да только новорег не такой простой оказался? Вот и приходится в спешном порядке цепляться к слову "компиляция" и утечкой памяти называть то, что ей не является, только бы сохранить "хорошую мину при плохой игре"?

Что вам от меня нужно? - Возьмите мой кошелек, только не насилуйте мозг..

KOPOJI · 27.08.2014, 19:31

Не по теме:

Сообщение от Tatikoma

Исправишь ошибку и утечка пропадет

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

Новые блоги и статьи Все статьи Все блоги /
Инструменты COM: Сохранение данный из VARIANT в файл и загрузка из файла в VARIANT bedvit 28.01.2026 Сохранение базовых типов COM и массивов (одномерных или двухмерных) любой вложенности (деревья) в файл, с возможностью выбора алгоритмов сжатия и шифрования. Часть библиотеки BedvitCOM Использованы. . .	Загрузка PNG с альфа-каналом на SDL3 для Android: с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 28.01.2026 Содержание блога SDL3 имеет собственные средства для загрузки и отображения PNG-файлов с альфа-каналом и базовой работы с ними. В этой инструкции используется функция SDL_LoadPNG(), которая. . .	Загрузка PNG с альфа-каналом на SDL3 для Android: с помощью SDL3_image 8Observer8 27.01.2026 Содержание блога SDL3_image - это библиотека для загрузки и работы с изображениями. Эта пошаговая инструкция покажет, как загрузить и вывести на экран смартфона картинку с альфа-каналом, то есть с. . .	Влияние грибов на сукцессию anaschu 26.01.2026 Бифуркационные изменения массы гриба происходят тогда, когда мы уменьшаем массу компоста в 10 раз, а скорость прироста биомассы уменьшаем в три раза. Скорость прироста биомассы может уменьшаться за. . .
Воспроизведение звукового файла с помощью SDL3_mixer при касании экрана Android 8Observer8 26.01.2026 Содержание блога SDL3_mixer - это библиотека я для воспроизведения аудио. В отличие от инструкции по добавлению текста код по проигрыванию звука уже содержится в шаблоне примера. Нужно только. . .	Установка Android SDK, NDK, JDK, CMake и т.д. 8Observer8 25.01.2026 Содержание блога Перейдите по ссылке: https:/ / developer. android. com/ studio и в самом низу страницы кликните по архиву "commandlinetools-win-xxxxxx_latest. zip" Извлеките архив и вы увидите. . .	Вывод текста со шрифтом TTF на Android с помощью библиотеки SDL3_ttf 8Observer8 25.01.2026 Содержание блога Если у вас не установлены Android SDK, NDK, JDK, и т. д. то сделайте это по следующей инструкции: Установка Android SDK, NDK, JDK, CMake и т. д. Сборка примера Скачайте. . .	Использование SDL3-callbacks вместо функции main() на Android, Desktop и WebAssembly 8Observer8 24.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .

@JamesHound 0 / 0 / 0 Регистрация: 27.08.2013 Сообщений: 8

	Выявить утечку памяти 23.08.2014, 21:44. Показов 7343. Ответов 19 Метки нет (Все метки) Здравствуйте. Написал парсер с библиотекой для парсинга simple_html_dom. После длительного парсинга видно, что память переполняется. Можно ли как то узнать, в каком месте идет переполнение памяти ? Профайлер может 0

@Tatikoma F́́́́́́́ŕ́́́́́́́é́́́ ́ak 260 / 224 / 109 Регистрация: 07.07.2014 Сообщений: 965
	24.08.2014, 17:57
	Пробовал ловить утечки памяти в большом проекте - дело совершенно неблагодарное. Первое что я сделал - попробовал повтыкать везде memory_get_usage, - ничего толком не получилось. Потом я попробовал подключится через отладчик, - повыполнять скрипт пошагово, посмотреть где какие-то свойства на новой итерации забываются.. ничего не нашел - было слишком много начинки внутри фреймворка. Потом пробовал различные профайлеры - они в принципе ничего не дали, кроме красивой картинки.. Еще помню пробовал играться с версией PHP, накатывать различные патчи.. ничего особо не помогло.. =) Затем я вернулся к первому способу и таки нашел утечку памяти.. в PECL'овом расширении amqp для PHP.. Соответственно не могу ничего конкретного посоветовать, - утечки памяти ловить сложнее других ошибок и конкретного рецепта как с ними бороться - не существует. 0

@asmprog 168 / 0 / 1 Регистрация: 25.08.2014 Сообщений: 6
	25.08.2014, 13:27
	simple_html_dom - это PHP библиотека, поэтому говорить об "утечке" памяти тут не приходится. PHP устроен так, что для каждой сессии(клиентского запроса от веб-сервера или другого SAPI) образует отдельный блок памяти(ограниченный сверху настройками), который привязан к этой сессии. Превышение лимита дает всем знакомое сообщение, в котором как раз и указано - где именно осуществляют попытку выделить очередной кусок из блока, который становится фатальным. Важно понимать, что не только PHP код может вызвать превышение лимита - каждый include`нутый файл представляет собой байт-код(+к использованной памяти), служебные структуры, описывающие контекст этого байт-кода(+к использованной памяти) и много чего еще(даже отложенное создание классов на деле реализовано как дублирование записи в соответствующей hash-таблице). По-сему: 1. unset переменных, которые далее по коду не нужны 2. повышение лимита в настройках 0

@V@D!k 249 / 249 / 98 Регистрация: 26.07.2010 Сообщений: 1,685
	25.08.2014, 14:46
	по-моему сам simple_html_dom довольно кривоватый, пользовался им, возникали такие же проблемы при больших объемах, поэтому если не слишком сложный парсинг, лучше использовать регулярки, также посоветовал бы вам обратить внимание на PHPQuery 0

@V@D!k 249 / 249 / 98 Регистрация: 26.07.2010 Сообщений: 1,685
	25.08.2014, 17:39
	увидел интересную ссылку, почитайте, может быть вам поможет p.s. самое главное в конце 0

@V@D!k 249 / 249 / 98 Регистрация: 26.07.2010 Сообщений: 1,685
	27.08.2014, 14:04
	я ошибаюсь, или человек парсит контент с другого сайта а не с xml? 0

KOPOJI Почетный модератор 16844 / 6724 / 880 Регистрация: 12.06.2012 Сообщений: 19,967
	27.08.2014, 14:06
	html, xml, какая разница.. А вот то, что с другого сайта - необязательно. Но если дело в этом, то, скорее всего, стоит сначала перекинуть контент к себе и парсить локально 0

@V@D!k 249 / 249 / 98 Регистрация: 26.07.2010 Сообщений: 1,685
	27.08.2014, 14:11
	наверное вы правы, но мы не узнаем истины, пока создатель темы не скажет, что он парсит 0

KOPOJI
	27.08.2014, 14:31
	Не по теме: Игорь[Igor], :D 0