memory leak

[Zoltán Süle]

        Sziasztok,


  Az a kerdesem, hogy mikent tudom megtalalni, hogy egy parancssorban
futo script melyik osztalya/metodusa okoz memoriaszivargast?
  kornyezet: PHP5, Zend FW, pgsql8.3,

  Adott egy fejlesztes, aminek a trunk agaban egy regebbi es egyszerubb
parancssori script van. Egy branchben pedig ennek a tovabbfejlesztett,
cache-elessel tamogatott valtozata, ahol a tovabbfejlesztes a rendszer
meghatarozo reszet erinti.

  A parancssori script egy importalo folyamatot vegez, amelynek soran a
rendszer sok osztalyat hasznalja, meglehetosen sok adatbazismuvelettel.

  A trunk agban levo script 5.8-6MB-os memoriahasznalattal mukodik es
dolgozza fel azt a 100 000-es nagysagrendu adatallomanyt, aminek a 10
000-dik soranal a branchbeli verzio memoriaelfogyas miatt kiakad (ekkor
eri el a 255MB-os hatart). Ennek a futtatasa soran jol latszik, ahogy
folyamatosan fogy a memoria.
  Eloszor azzal probalkoztam, hogy unset-eltem a felesleges objektumokat
es az erintett osztalyokban destruktorokkal is megsemmisitettem a belso
valtozokat. Semmit nem segitett (raadasul a trunk agban sincsenek
unset-elve es destruktorok sincsenek irva). Kikapcsoltam a cache-elest,
mert eleinte arra gyanakodtunk.
  Kollegam javaslatara Xdebug profiler-rel is megneztem, de abban nem
talaltam informaciot arra vonatkozoan, hogy melyik kodreszlet emeszti
fel a memoriat.


  A kod merete es osszetettsege miatt nincs arra mod, hogy sorrol-sorra
osszehasonlitsuk a ket fejlesztoi agat.

  Talalkozott valaki mar hasonloval? Mikent lehet megtalalni a rest?


        koszi,
Zoli

--
Weblabor hírlevél: http://weblabor.hu/hirlevel
--
wl-phplista (wl-phplista@...) levelezőlista
https://bors.hoszting.com/mailman/listinfo/wl-phplista
Keresheto archivum: http://weblabor.hu/kereses
--
etikett: http://weblabor.hu/levlistak/illemszabaly
offlista: https://weblabor.hu/levlistak

[dragon-8]

>   Kollegam javaslatara Xdebug profiler-rel is megneztem, de abban nem
> talaltam informaciot arra vonatkozoan, hogy melyik kodreszlet emeszti
> fel a memoriat.
>
>
>  
Esetleg probáld meg Zend debugerrel, az is ingyenes, de többet tud.

dragon
--
Weblabor hírlevél: http://weblabor.hu/hirlevel
--
wl-phplista (wl-phplista@...) levelezőlista
https://bors.hoszting.com/mailman/listinfo/wl-phplista
Keresheto archivum: http://weblabor.hu/kereses
--
etikett: http://weblabor.hu/levlistak/illemszabaly
offlista: https://weblabor.hu/levlistak

[felho]

>   Az a kerdesem, hogy mikent tudom megtalalni, hogy egy parancssorban
> futo script melyik osztalya/metodusa okoz memoriaszivargast?
Szvsz erre kész eszközt nem fogsz találni. Kb. két irányt tudnék elképzelni.

1. Ehhez nem értek, de el tudom képzelni, hogy vannak PHP-től független
rendszer közeli eszközök (dtrace, valgrind vagy valami ilyesmi), amikkel
meg lehet találni, hogy kb. hol fogy folyamatosan a memória, ebből az
infóból már esetleg könnyen vissza lehet következtetni, hogy a PHP
szintjén ezt melyik osztály okozza.

2. A másik, hogy memory_get_usage() parancsokat pakolsz a ciklusba több
helyre, és nézed, hogy hol növekszik folyamatosan. Ezzel szépen be lehet
szűkíteni a problémás részt.


Üdv,
Felhő
--
Weblabor hírlevél: http://weblabor.hu/hirlevel
--
wl-phplista (wl-phplista@...) levelezőlista
https://bors.hoszting.com/mailman/listinfo/wl-phplista
Keresheto archivum: http://weblabor.hu/kereses
--
etikett: http://weblabor.hu/levlistak/illemszabaly
offlista: https://weblabor.hu/levlistak

[Heilig Szabolcs]

Helló!

 > Az a kerdesem, hogy mikent tudom megtalalni, hogy egy parancssorban
 > futo script melyik osztalya/metodusa okoz memoriaszivargast?
 > kornyezet: PHP5, Zend FW, pgsql8.3,

Simán lehet, hogy abba a leak problémába futottál bele, mint anno
amikor Propel-ben volt hasonló szívásod, szintén importáláskor.
A sok kereszthivatkozás miatt Az 5.2-es vagy régebbi PHP-k nem
tudják felszabadítani a memóriát, még ha unset()-elsz sem. Ha
van rá lehetőséged, próbáld ki 5.3-as PHP-vel, aminek jóval
fejlettebb a garbage collector algoritmusa, amire pontosan
az ilyen hibák miatt van szükség.

Felhő memory_get_usage() javaslata mellett a szivárgás helyének
megtalálására az xdebug is segítségedre lehet, azzal is
lehet egy teljes logot kérni, amiben benne van minden egyes
hívás, annak futási ideje és persze követhető a memóriahasználat
alakulása is.

Ha megvan a hiba, de nem orvosolható, akkor még megfontolható
az is, hogy az import scripted kissebb szakaszokban hajtsa végre
az importálást, azaz egy futás alkalmával pl csak 100 tételt
dolgoz fel. Tudom, ez most nem volt kérdés... :)

--
Heilig Szabolcs
cece@... - http://devolver.hu (SVN, Trac hoszting)
--
Weblabor hírlevél: http://weblabor.hu/hirlevel
--
wl-phplista (wl-phplista@...) levelezőlista
https://bors.hoszting.com/mailman/listinfo/wl-phplista
Keresheto archivum: http://weblabor.hu/kereses
--
etikett: http://weblabor.hu/levlistak/illemszabaly
offlista: https://weblabor.hu/levlistak

[JoE-255]

Szia!

Ha jól rémlik, a PHP-APD tudott ilyen profile riportot nyomni, amiben a
hívási idők- és dbszámok mellett a memóriahasználatról is volt némi
információ; nemt'om, manapság/nálatok még használható-e ilyesmire.


Üdv,
JoE


Zoltán Süle írta:

> Sziasztok,
>
>
>   Az a kerdesem, hogy mikent tudom megtalalni, hogy egy parancssorban
> futo script melyik osztalya/metodusa okoz memoriaszivargast?
>   kornyezet: PHP5, Zend FW, pgsql8.3,
>
>   Adott egy fejlesztes, aminek a trunk agaban egy regebbi es egyszerubb
> parancssori script van. Egy branchben pedig ennek a tovabbfejlesztett,
> cache-elessel tamogatott valtozata, ahol a tovabbfejlesztes a rendszer
> meghatarozo reszet erinti.
>
>   A parancssori script egy importalo folyamatot vegez, amelynek soran a
> rendszer sok osztalyat hasznalja, meglehetosen sok adatbazismuvelettel.
>
>   A trunk agban levo script 5.8-6MB-os memoriahasznalattal mukodik es
> dolgozza fel azt a 100 000-es nagysagrendu adatallomanyt, aminek a 10
> 000-dik soranal a branchbeli verzio memoriaelfogyas miatt kiakad (ekkor
> eri el a 255MB-os hatart). Ennek a futtatasa soran jol latszik, ahogy
> folyamatosan fogy a memoria.
>   Eloszor azzal probalkoztam, hogy unset-eltem a felesleges objektumokat
> es az erintett osztalyokban destruktorokkal is megsemmisitettem a belso
> valtozokat. Semmit nem segitett (raadasul a trunk agban sincsenek
> unset-elve es destruktorok sincsenek irva). Kikapcsoltam a cache-elest,
> mert eleinte arra gyanakodtunk.
>   Kollegam javaslatara Xdebug profiler-rel is megneztem, de abban nem
> talaltam informaciot arra vonatkozoan, hogy melyik kodreszlet emeszti
> fel a memoriat.
>
>
>   A kod merete es osszetettsege miatt nincs arra mod, hogy sorrol-sorra
> osszehasonlitsuk a ket fejlesztoi agat.
>
>   Talalkozott valaki mar hasonloval? Mikent lehet megtalalni a rest?
>
>
> koszi,
> Zoli
>

--
Weblabor hírlevél: http://weblabor.hu/hirlevel
--
wl-phplista (wl-phplista@...) levelezőlista
https://bors.hoszting.com/mailman/listinfo/wl-phplista
Keresheto archivum: http://weblabor.hu/kereses
--
etikett: http://weblabor.hu/levlistak/illemszabaly
offlista: https://weblabor.hu/levlistak

[Zoltán Süle]

        Szaisztok,


  Koszi az otleteket!


> Simán lehet, hogy abba a leak problémába futottál bele, mint anno
> amikor Propel-ben volt hasonló szívásod, szintén importáláskor.

  Mikozben ezzel szivtam, eszembe jutott az az eset.
  S mivel most van ket scriptem ket fejlesztoi agban es az egyik elfut
6MB memoriaban, a masik pedig 1GB-ig sem allna meg, erosen
elgondolkodtam azon, hogy vajon tenyleg a propel volt-e a hibas?


> A sok kereszthivatkozás miatt Az 5.2-es vagy régebbi PHP-k nem
> tudják felszabadítani a memóriát, még ha unset()-elsz sem.

  A fentiek miatt azt gondolom, hogy programozoi hibat kovettem el,
mivel a ket kornyezet nem kulonbozik a ket futtatas soran.


> Ha
> van rá lehetőséged, próbáld ki 5.3-as PHP-vel, aminek jóval
> fejlettebb a garbage collector algoritmusa, amire pontosan
> az ilyen hibák miatt van szükség.

  Ez fontos info!


> Felhő memory_get_usage() javaslata mellett a szivárgás helyének
> megtalálására az xdebug is segítségedre lehet, azzal is
> lehet egy teljes logot kérni, amiben benne van minden egyes
> hívás, annak futási ideje és persze követhető a memóriahasználat
> alakulása is.

  Az xdebug kimenetet a KCacheGrind-el neztem. Abban nem talaltam
informaciot a memoriahasznalatra vonatkozoan. Csak futasi idoket lattam,
ami a hiba szempontjabol nem relevans.
  Utannajarok!


> Ha megvan a hiba, de nem orvosolható, akkor még megfontolható
> az is, hogy az import scripted kissebb szakaszokban hajtsa végre
> az importálást, azaz egy futás alkalmával pl csak 100 tételt
> dolgoz fel. Tudom, ez most nem volt kérdés... :)

  Igen, vegso esetben ez lehet megoldas, de ez nem valami elegans.


Z
--
Weblabor hírlevél: http://weblabor.hu/hirlevel
--
wl-phplista (wl-phplista@...) levelezőlista
https://bors.hoszting.com/mailman/listinfo/wl-phplista
Keresheto archivum: http://weblabor.hu/kereses
--
etikett: http://weblabor.hu/levlistak/illemszabaly
offlista: https://weblabor.hu/levlistak

[Zoltán Süle]

        Szia Cece,


> Felhő memory_get_usage() javaslata mellett a szivárgás helyének

  Nekialltam ekeppen megtalalni, de a hajam kihullik, mire igy ralelek a
hiba forrasara. Raadasul mindig a Zend core-ban lyukadok ki, aminek
semmi ertelme, mert a fofejlesztesi ag es a branch azonos verzioju
Zend-et hasznal, csak esetlegesen a konfiguraciok kulonbozhetnek.


> megtalálására az xdebug is segítségedre lehet, azzal is
> lehet egy teljes logot kérni, amiben benne van minden egyes
> hívás, annak futási ideje és persze követhető a memóriahasználat
> alakulása is.

  Tudsz grafikus eszkozt linux alatt, ami megmutatja nekem az xdebug-al
eloallitott log-bol a memoria hasznalatot?
  KCacheGrind-et nem tudom ravenni es a futasi ido jelen esetben
elegtelen informacio. Interneten nem talalok okossagot.

Ezen beallitas menten hasznalom:

[debug]
; Remote settings
xdebug.remote_autostart=off
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=localhost
xdebug.remote_port=9000

; General
xdebug.auto_trace=on
xdebug.collect_includes=on
xdebug.collect_params=on
xdebug.collect_return=on
xdebug.default_enable=on
xdebug.extended_info=1
xdebug.manual_url=http://www.php.net
xdebug.show_local_vars=0
;
xdebug.show_mem_delta=1
xdebug.max_nesting_level=100
;xdebug.idekey=

; Trace options
xdebug.trace_format=0
xdebug.trace_output_dir=/tmp
xdebug.trace_options=0
xdebug.trace_output_name=crc32

; Profiling
xdebug.profiler_append=0
xdebug.profiler_enable=1
xdebug.profiler_enable_trigger=0
xdebug.profiler_output_dir=/tmp
xdebug.profiler_output_name=crc32_term

  Keletkezik egy crc32.xt nevu file is, de azt nem tudom mivel
megjelenittetni.


Z
--
Weblabor hírlevél: http://weblabor.hu/hirlevel
--
wl-phplista (wl-phplista@...) levelezőlista
https://bors.hoszting.com/mailman/listinfo/wl-phplista
Keresheto archivum: http://weblabor.hu/kereses
--
etikett: http://weblabor.hu/levlistak/illemszabaly
offlista: https://weblabor.hu/levlistak

[Ámon Tamás]

Szia!

2009/8/13 Zoltán Süle <zoltan.sule@...>:
>
>        Sziasztok,

>  A kod merete es osszetettsege miatt nincs arra mod, hogy sorrol-sorra
> osszehasonlitsuk a ket fejlesztoi agat.
>
>  Talalkozott valaki mar hasonloval? Mikent lehet megtalalni a rest?
>
>

Nekem is egy drupalos importnal volt hasonlo problemam, mondjuk ott
mysql volt. Nem nagyon masztam bele, megoldottam mas modszerrel, de
szerintem valami sql-es lekerdezeshez van koze. mintha a korabbi
sorokat a resultbol beletenne valahova a memoriaba. Mondjuk engem is
erdekelne a megoldas.
--
Ámon Tamás
--
Weblabor hírlevél: http://weblabor.hu/hirlevel
--
wl-phplista (wl-phplista@...) levelezőlista
https://bors.hoszting.com/mailman/listinfo/wl-phplista
Keresheto archivum: http://weblabor.hu/kereses
--
etikett: http://weblabor.hu/levlistak/illemszabaly
offlista: https://weblabor.hu/levlistak

[Veres Lajos]

Szia,

Egy próbát ezzel is lehet esetleg tenni:
get_defined_vars()
És iterációnként csekkolni, hogy mi nő benne.
Vagy csak fileba irogatni iterációnként és utána diffelgetni a fileokat.

Bár mivel vszleg valami rekurziv egymásramutogatós cucc lesz, ezért a
kiiratás/feldolgozás se biztos, hogy triviális lesz...

On Thu, 13 Aug 2009, Zoltán Süle wrote:

>
> Sziasztok,
>
>
>   Az a kerdesem, hogy mikent tudom megtalalni, hogy egy parancssorban
> futo script melyik osztalya/metodusa okoz memoriaszivargast?
>   kornyezet: PHP5, Zend FW, pgsql8.3,
>
>   Adott egy fejlesztes, aminek a trunk agaban egy regebbi es egyszerubb
> parancssori script van. Egy branchben pedig ennek a tovabbfejlesztett,
> cache-elessel tamogatott valtozata, ahol a tovabbfejlesztes a rendszer
> meghatarozo reszet erinti.
>
>   A parancssori script egy importalo folyamatot vegez, amelynek soran a
> rendszer sok osztalyat hasznalja, meglehetosen sok adatbazismuvelettel.
>
>   A trunk agban levo script 5.8-6MB-os memoriahasznalattal mukodik es
> dolgozza fel azt a 100 000-es nagysagrendu adatallomanyt, aminek a 10
> 000-dik soranal a branchbeli verzio memoriaelfogyas miatt kiakad (ekkor
> eri el a 255MB-os hatart). Ennek a futtatasa soran jol latszik, ahogy
> folyamatosan fogy a memoria.
>   Eloszor azzal probalkoztam, hogy unset-eltem a felesleges objektumokat
> es az erintett osztalyokban destruktorokkal is megsemmisitettem a belso
> valtozokat. Semmit nem segitett (raadasul a trunk agban sincsenek
> unset-elve es destruktorok sincsenek irva). Kikapcsoltam a cache-elest,
> mert eleinte arra gyanakodtunk.
>   Kollegam javaslatara Xdebug profiler-rel is megneztem, de abban nem
> talaltam informaciot arra vonatkozoan, hogy melyik kodreszlet emeszti
> fel a memoriat.
>
>
>   A kod merete es osszetettsege miatt nincs arra mod, hogy sorrol-sorra
> osszehasonlitsuk a ket fejlesztoi agat.
>
>   Talalkozott valaki mar hasonloval? Mikent lehet megtalalni a rest?
>
>
> koszi,
> Zoli
>
>

--
Veres Lajos
vlajos@...
[phone]
--
Weblabor hírlevél: http://weblabor.hu/hirlevel
--
wl-phplista (wl-phplista@...) levelezőlista
https://bors.hoszting.com/mailman/listinfo/wl-phplista
Keresheto archivum: http://weblabor.hu/kereses
--
etikett: http://weblabor.hu/levlistak/illemszabaly
offlista: https://weblabor.hu/levlistak

[Szabolcs Sulik]

Szia

Azt megtudhatjuk, hogy milyen ORM-et hasznalsz? (hasznalsz orm-et?)

Doctrine eseten gyonyoru szivasok voltak ezzel kapcsolatban. (gondolom hasonlo a te Propeles dolgodhoz) A megoldas az lett: PDO-n keresztul sql, buffered query-kent.

udv
Szabolcs


--- On Thu, 8/13/09, Zoltán Süle <zoltan.sule@...> wrote:

> From: Zoltán Süle <zoltan.sule@...>
> Subject: [wl-phplista] memory leak
> To: "weblabor PHP levlista" <wl-phplista@...>
> Date: Thursday, August 13, 2009, 2:06 PM
>
>     Sziasztok,
>
>
>   Az a kerdesem, hogy mikent tudom megtalalni, hogy
> egy parancssorban
> futo script melyik osztalya/metodusa okoz
> memoriaszivargast?
>   kornyezet: PHP5, Zend FW, pgsql8.3,
>
>   Adott egy fejlesztes, aminek a trunk agaban egy
> regebbi es egyszerubb
> parancssori script van. Egy branchben pedig ennek a
> tovabbfejlesztett,
> cache-elessel tamogatott valtozata, ahol a tovabbfejlesztes
> a rendszer
> meghatarozo reszet erinti.
>
>   A parancssori script egy importalo folyamatot vegez,
> amelynek soran a
> rendszer sok osztalyat hasznalja, meglehetosen sok
> adatbazismuvelettel.
>
>   A trunk agban levo script 5.8-6MB-os
> memoriahasznalattal mukodik es
> dolgozza fel azt a 100 000-es nagysagrendu adatallomanyt,
> aminek a 10
> 000-dik soranal a branchbeli verzio memoriaelfogyas miatt
> kiakad (ekkor
> eri el a 255MB-os hatart). Ennek a futtatasa soran jol
> latszik, ahogy
> folyamatosan fogy a memoria.
>   Eloszor azzal probalkoztam, hogy unset-eltem a
> felesleges objektumokat
> es az erintett osztalyokban destruktorokkal is
> megsemmisitettem a belso
> valtozokat. Semmit nem segitett (raadasul a trunk agban
> sincsenek
> unset-elve es destruktorok sincsenek irva). Kikapcsoltam a
> cache-elest,
> mert eleinte arra gyanakodtunk.
>   Kollegam javaslatara Xdebug profiler-rel is
> megneztem, de abban nem
> talaltam informaciot arra vonatkozoan, hogy melyik
> kodreszlet emeszti
> fel a memoriat.
>
>
>   A kod merete es osszetettsege miatt nincs arra mod,
> hogy sorrol-sorra
> osszehasonlitsuk a ket fejlesztoi agat.
>
>   Talalkozott valaki mar hasonloval? Mikent lehet
> megtalalni a rest?
>
>
>     koszi,
> Zoli
>
> --
> Weblabor hírlevél: http://weblabor.hu/hirlevel
> --
> wl-phplista (wl-phplista@...)
> levelezőlista
> https://bors.hoszting.com/mailman/listinfo/wl-phplista
> Keresheto archivum: http://weblabor.hu/kereses
> --
> etikett: http://weblabor.hu/levlistak/illemszabaly
> offlista: https://weblabor.hu/levlistak
>

     

--
Weblabor hírlevél: http://weblabor.hu/hirlevel
--
wl-phplista (wl-phplista@...) levelezőlista
https://bors.hoszting.com/mailman/listinfo/wl-phplista
Keresheto archivum: http://weblabor.hu/kereses
--
etikett: http://weblabor.hu/levlistak/illemszabaly
offlista: https://weblabor.hu/levlistak

[Zoltán Süle]

        Szia Szabolcs,


> Azt megtudhatjuk, hogy milyen ORM-et hasznalsz? (hasznalsz orm-et?)

  jelen esetben nem hasznalok ORM-et. A Zend Framework altal biztositott
Zend DB feluleten keresztul erem el az adatbazist.
  Idokozben egyebkent tortent egy furasag, amit nem tudok mashoz
kapcsolni csak ahhoz, hogy frissult a PHP csomag, mivel a jelenseg
megszunt. A memoriaigeny ismet 6 es 40MB kozotti es a maghoz tovabbra
sem nyultunk.


> Doctrine eseten gyonyoru szivasok voltak ezzel kapcsolatban. (gondolom hasonlo a te Propeles dolgodhoz) A megoldas az lett: PDO-n keresztul sql, buffered query-kent.

  En is tobb helyrol azt a visszajelzest kaptam, hogy a PDO oldotta meg
ezeket a memoria szivargasokat.


Z
--
Weblabor hírlevél: http://weblabor.hu/hirlevel
--
wl-phplista (wl-phplista@...) levelezőlista
https://bors.hoszting.com/mailman/listinfo/wl-phplista
Keresheto archivum: http://weblabor.hu/kereses
--
etikett: http://weblabor.hu/levlistak/illemszabaly
offlista: https://weblabor.hu/levlistak