IIS7/PHP 5.3.5 SoapClient out of memory na volle disk

[gnoe93]

We hebben een legacy server draaien waarop een PHP script via SOAP gevevens uit een database ophaalt op een andere server. Een paar dagen geleden had de server met het PHP script een volle disk, wat ondertussen is opgelost, maar sindsdien geeft de SOAP client een out of memory exception:

code:

SoapFault exception: [Client] Allowed memory size of 536870912 bytes exhausted (tried to allocate 41480192 bytes) in D:\inetpub\ftproot\wwwroot\dtliikennetietofi\commandline_tasks\libs\sqlcall_class_tip20_prod.php:62
Stack trace:
#0 [internal function]: SoapClient->__doRequest('<?xml version="...', 'http://soap.mmn...', '', 1, 0)
#1 D:\inetpub\ftproot\wwwroot\dtliikennetietofi\commandline_tasks\libs\sqlcall_class_tip20_prod.php(62): SoapClient->__call('GetDataFromDB', Array)
#2 D:\inetpub\ftproot\wwwroot\dtliikennetietofi\commandline_tasks\import_fi_finnra_d2\get_live_events_from_tip.php(60): sqlcall->sqlrequest('select vvguid,s...')
#3 D:\inetpub\ftproot\wwwroot\dtliikennetietofi\commandline_tasks\import_fi_finnra_d2\get_live_events_from_tip.php(9): give_events_from_db()
#4 D:\inetpub\ftproot\wwwroot\dtliikennetietofi\commandline_tasks\import_fi_finnra_d2\index.php(59): include('D:\\inetpub\\ftpr...')
#5 {main}

Het gaat hem om PHP versie 5.3.5 in IIS 7 op Windows Server 2008 R Enterprise.

Ik heb kunnen bevestigen dat de SOAP server zelf steeds de requests ontvangt en correct afhandelt. Het is dus uitsluitend een client error (zoals aangegeven in de stack trace). Het eigenaardige is dat het teruggegeven resultaat met SOAP nooit groter is dan 20MB.

Ik heb iemand met een gelijkaardig probleem gevonden, maar zijn uitleg/oplossing is niet echt duidelijk: https://stackoverflow.com...ory-size-using-soapclient. Ik heb in ieder geval geprobeerd de WSDL lokaal te laden, maar zonder resultaat.

Verder heb ik reeds geprobeerd de WSDL cache uit te zetten/clearen, maar ook dit zonder resultaat.

Een ander vermoeden is dat het mogelijks om een memory leak/bug gaat: https://bugs.php.net/bug.php?id=70900, maar dan zou ik verwachten dat de SoapClient faalt bij het aanroepen van de constructor, wat bij mij niet het geval is. Sommige SOAP requests slagen zelfs; het lijkt er op dat de client steeds op dezelfde query crasht.

[ Voor 7% gewijzigd door gnoe93 op 02-09-2020 20:53 ]

[eLScha]

Probleem speelt zich af op regel 62. Kun je regel 50 tot 65 eens delen?

Zit de soapcall in een loop?

[DJMaze]

Zo te zien gebruik je meer dan 512MB aan geheugen.
Ruim je geheugengebruik op in de db gebruik.

[ Voor 9% gewijzigd door DJMaze op 02-09-2020 22:09 ]

[Harrie_]

Ik weet niet onder welke voorwaarden je die gegevens ophaalt, maar het is natuurlijk niet ondenkelijk dat je alleen nieuwe data ophaalt.

Is het probleem niet gewoon simpelweg dat er téveel nieuwe data wordt geleverd omdat het script tijdelijk niet heeft gewerkt? Als je onder normale omstandigheden ieder uur 1.000 nieuwe rows aan data ophaalt, maar het script heeft 24 uur niet gewerkt dan zal hij nu 24.000+ rows returnen waarbij PHP niet genoeg geheugen heeft om al die data te parsen (zeker niet als je er clientside ook nog eens doorheen gaat lopen loopen en weet ik wat al niet meer)...

[gnoe93]

eLScha schreef op woensdag 2 september 2020 @ 22:01:
Probleem speelt zich af op regel 62. Kun je regel 50 tot 65 eens delen?

Zit de soapcall in een loop?

De regels er voor zijn gewoon parameters die meegegeven worden. Zit niet in een loop, het is de enige call die uitgevoerd wordt.

DJMaze schreef op woensdag 2 september 2020 @ 22:07:
Zo te zien gebruik je meer dan 512MB aan geheugen.
Ruim je geheugengebruik op in de db gebruik.

Harrie_ schreef op woensdag 2 september 2020 @ 22:41:
Ik weet niet onder welke voorwaarden je die gegevens ophaalt, maar het is natuurlijk niet ondenkelijk dat je alleen nieuwe data ophaalt.

Is het probleem niet gewoon simpelweg dat er téveel nieuwe data wordt geleverd omdat het script tijdelijk niet heeft gewerkt? Als je onder normale omstandigheden ieder uur 1.000 nieuwe rows aan data ophaalt, maar het script heeft 24 uur niet gewerkt dan zal hij nu 24.000+ rows returnen waarbij PHP niet genoeg geheugen heeft om al die data te parsen (zeker niet als je er clientside ook nog eens doorheen gaat lopen loopen en weet ik wat al niet meer)...

Dat was inderdaad een van mijn eerste vermoedens, maar er is sinds de dag van de volle schijf geen nieuwe data meer binnengekomen in de database. Zoals ik eerder al zei, is data die de SOAP call returnt, rond de 20MB.

Bovendien wordt SOAP call wordt altijd zonder uitzondering succesvol verstuurd, ontvangen en verwerkt, maar dan loopt het fout in de client zelf die het resultaat terug ontvangt. De out of memory gebeurt in de SOAP client zelf, zonder dat ik het resultaat kan verwerken/lezen. Het zou me verbazen dat de interne logica van SoapClient meer dan 500MB aan geheugen nodig heeft om een XML van 25MB te lezen?

[ Voor 16% gewijzigd door gnoe93 op 03-09-2020 01:23 ]

[Harrie_]

gnoe93 schreef op donderdag 3 september 2020 @ 01:19:
[...]
Dat was inderdaad een van mijn eerste vermoedens, maar er is sinds de dag van de volle schijf geen nieuwe data meer binnengekomen in de database. Zoals ik eerder al zei, is data die de SOAP call returnt, rond de 20MB.

Bovendien wordt SOAP call wordt altijd zonder uitzondering succesvol verstuurd, ontvangen en verwerkt, maar dan loopt het fout in de client zelf die het resultaat terug ontvangt. De out of memory gebeurt in de SOAP client zelf, zonder dat ik het resultaat kan verwerken/lezen. Het zou me verbazen dat de interne logica van SoapClient meer dan 500MB aan geheugen nodig heeft om een XML van 25MB te lezen?

Ik sluit met dan wel aan bij @eLScha met de vraag om de relevante regels te posten waarop het geheugen volloopt.

Het is toch niet geheel ondenkelijk dat er in de SOAP client zelf iets van een loop plaatsvind? Ik weet niet wat er precies met de data gebeurt, maar 25MB lijkt misschien 'weinig' totdat die soapclient van iedere regel een assoc array gaat bakken en er ook nog iets aan validatie op uit gaat voeren...

[thlst]

gnoe93 schreef op woensdag 2 september 2020 @ 20:50:
Sommige SOAP requests slagen zelfs

Gewoon memory_limit verhogen

[DJMaze]

gnoe93 schreef op donderdag 3 september 2020 @ 01:19:
Het zou me verbazen dat de interne logica van SoapClient meer dan 500MB aan geheugen nodig heeft om een XML van 25MB te lezen?

Meten is weten met memory_get_usage en memory_get_peak_usage

thlst schreef op donderdag 3 september 2020 @ 09:20:
Gewoon memory_limit verhogen

offtopic:
Het is geen WordPress website

[Harrie_]

@gnoe93 Ben je nog verder gekomen? Is het inmiddels opgelost?