[PHP] Memory leak

[Verwijderd]

Ik blijk een hele rare bug te hebben met php/apache.

Met Redhat 7.3 (php 4.2.2 en apache 1.3.22) had ik nergens last van.

Maar nadat ik upgrade naar RedHat 9.0 (php 4.2.2 en apache 2.0.40) lijkt PHP last te hebben van een memory leak.

Na zo'n 4500 hits is de geheugen verbreuk opgelopen naar de 8MB en krijg ik de error "Memory limit of ... exhausted (failed to allocate ... bytes)".
Dit probleem lost zich pas op als je apache restart.

Ik heb nu tijdelijk "MaxRequestsPerChild" op 100 gezet, dit zorgt ervoor dat alle processen op tijd worden gerestart en de memory die PHP gebruikt wordt geleegd.

Dit is natuurlijk niet erg efficient en de memory leak blijft bestaan.


Nog een probleem dat ik heb ontdekt tijdens de zoektocht naar de memory leak is een apache childprocess op hol slaat.
Zodra ik een "wget -r 'url'" uitvoer (download de pagina, en alle pagina's waarmee die in verbinding staat op de zelfde server) dan stijgt de cpu gebruik van 1 childprocess van apache naar 100% en zie je de memory gebruik erg snel stijgen naar ongeveer 30 MB.

Lijkt mij dat ik te kampen heb met 2 erg vervelende bugs, en weet geen oplossing te vinden hiervoor.

[chem]

Zeker een script dat gebruik maakt van $var =& $var2; truukjes?

[PowerSp00n]

Verwijderd schreef op 05 december 2003 @ 15:50:
php 4.2.2 en apache 2.0.40

Je gebruikt nou ook niet echt de nieuwste versies huh ?

[simon]

PowerSp00n schreef op 05 december 2003 @ 15:59:
[...]


Je gebruikt nou ook niet echt de nieuwste versies huh ?

Dat lijkt me het niet, het lijkt me eerder de 'ranzige' constructies waar Chem het over heeft. Maar upgraden kan nooit kwaad

[Verwijderd]

Simon schreef op 05 december 2003 @ 16:00:

Dat lijkt me het niet, het lijkt me eerder de 'ranzige' constructies waar Chem het over heeft. Maar upgraden kan nooit kwaad

En wat is er dan ranzig aan? Dat PHP er ranzig mee omging/omgaat, dát is ranzig. Maar wat mij betreft is er niets mis met het gebruiken van references, zeker niet waar het objecten en arrays betreft.

Ik zou dus echt het eerst proberen te upgraden naar nieuwere versies van PHP en Apache. Als het probleem er dan nog steeds is, dan is het jammer, maar dan kan PHP niet goed met je code overweg, en zul je daar het een en ander in moeten wijzigen zodat je minder kans hebt op memory leaks.

[mjax]

Verwijderd schreef op 05 december 2003 @ 16:05:
[...]

En wat is er dan ranzig aan? Dat PHP er ranzig mee omging/omgaat, dát is ranzig. Maar wat mij betreft is er niets mis met het gebruiken van references, zeker niet waar het objecten en arrays betreft.
.

Helemaal mee eens. Garbage collection is een taak van PHP en als die het niet goed doet, moet je niet de schuld neerleggen bij zogenaamd "ranzige constructies"...

[Suepahfly]

Heeft PHP uberhaubt garbagecollection dan. Ik heb iig nog nooit iets over gelezen.
Het OS maakt toch weer geheugen vrij als je script af sterft

[mjax]

Suepahfly schreef op 05 december 2003 @ 16:32:
Heeft PHP uberhaubt garbagecollection dan. Ik heb iig nog nooit iets over gelezen.
Het OS maakt toch weer geheugen vrij als je script af sterft

PHP heeft wel degelijk GB.

Je kunt het gedrag van de GB zelfs enigszins beinvloeden vanuit php.ini. Zo heb je de volgende parameters m.b.t. GB:

session.gc_maxlifetime
session.gc_probability

[ACM]

en wat heeft de session-gb met het geheugen gb te maken
php heeft, bij mijn weten, geen garbage collection, maar de php engine maakt als het goed is wel na het uitvoeren het geheugen dat het allocated had weer vrij (het apacheprocess sterft meestal niet) en daar kan idd memory leaking bij optreden.

[ Voor 69% gewijzigd door ACM op 05-12-2003 19:21 ]

[Verwijderd]

Wat ik momenteel aan het doen ben, is de script aan het doorlopen op 'rare scriptsels'. Ik heb de code niet zelf geschreven, maar is door iemand gedaan die gewend is met C te programmeren.
Zo komt het wel eens voor dat er <> als operator staat ipv !=.
Ook is de code wat verouderd. Het maakt niet gebruikt van de global variables zoals $_GET, $_POST of $_SERVER. En wordt er nog gebruik gemaakt van oude postgresql functies (vanaf 4.2.0 vond PHP het nodig om een aantal functies te hernoemen).

PHP blijkt niet echt backwards compatible te zijn met oude code.


Het vaagste is nog steeds wanneer een HTTP childproces ontspoord en zelfs na het sluiten van de pagina door blijft lopen en op het gegeven moment gewoon echt hangt. Zo heeft een server laatst een load average van meer dan 20 gehad.

Wat ik mij afvraag is waarom redhat 9.0 php versie 4.2.2 heeft en redhat 8.0 ook php 4.2.2 met een aantal minder fixes. Tussen de release van 8.0 en 9.0 zit zeker een half jaar en lijkt mij een overgang naar een nieuwe versie van PHP niet ondenkbaar.

[ Voor 5% gewijzigd door Verwijderd op 05-12-2003 22:09 ]