Zlib laat PHP-script stoppen
Mijn vraag
Ik heb net iets heel vreemd ontdekt. Ik heb een PHP-script die om een of andere reden op een bepaalde result uit mijn database lijkt te stoppen. Dit is de log, waar ik weinig wijzer van word. De code kan ik ook aanleveren als jullie willen, maar ik durf te wedden dat daar niks mis mee is, omdat het op andere results uit de database wel werkt. Zelf op de 1-op-1 testomgeving gaat het goed.
Alleen live weer niet... :S
Relevante software en hardware die ik gebruik
Eigen VPS met Directadmin
Cloudflare
Wat ik al gevonden of geprobeerd heb
Niet gek veel gevonden. Maar het lijkt erop dat zlib zich ergens in verslikt?
Ik heb PHP en Apache al herstart. Ook heb ik het geheugenverbruik op de VPS bekeken, en daar is ook niks mis mee. Maar het probleem blijft.
Toevoeging op 16/03/2021 19:43:08:
php_flag zlib.output_compression On
Gebruikt in php.ini en het werkt weer.
Raar, maar waar....
Ik heb net iets heel vreemd ontdekt. Ik heb een PHP-script die om een of andere reden op een bepaalde result uit mijn database lijkt te stoppen. Dit is de log, waar ik weinig wijzer van word. De code kan ik ook aanleveren als jullie willen, maar ik durf te wedden dat daar niks mis mee is, omdat het op andere results uit de database wel werkt. Zelf op de 1-op-1 testomgeving gaat het goed.
Alleen live weer niet... :S
Code (php)
1
2
3
2
3
[Tue Mar 16 19:00:55.952887 2021] [deflate:error] [pid 31910:tid 139924382566144] [client ***:***:***:1:753f:3967:77cf:392f:13688] AH01386: Zlib error -2 deflating data ((null)), referer: https://www.*******.nl/*****/index.php?module=********&action=materieelnummers_multiedit
[Tue Mar 16 19:00:55.952903 2021] [proxy_fcgi:error] [pid 31910:tid 139924382566144] (20014)Internal error (specific information not available): [client ***:***:***:1:753f:3967:77cf:392f:13688] AH01075: Error dispatching request to : (passing brigade to output filters), referer: https://www.******.nl/******/index.php?module=********&action=materieelnummers_multiedit
[Tue Mar 16 19:00:55.952903 2021] [proxy_fcgi:error] [pid 31910:tid 139924382566144] (20014)Internal error (specific information not available): [client ***:***:***:1:753f:3967:77cf:392f:13688] AH01075: Error dispatching request to : (passing brigade to output filters), referer: https://www.******.nl/******/index.php?module=********&action=materieelnummers_multiedit
Relevante software en hardware die ik gebruik
Eigen VPS met Directadmin
Cloudflare
Wat ik al gevonden of geprobeerd heb
Niet gek veel gevonden. Maar het lijkt erop dat zlib zich ergens in verslikt?
Ik heb PHP en Apache al herstart. Ook heb ik het geheugenverbruik op de VPS bekeken, en daar is ook niks mis mee. Maar het probleem blijft.
Toevoeging op 16/03/2021 19:43:08:
php_flag zlib.output_compression On
Gebruikt in php.ini en het werkt weer.
Raar, maar waar....
Waarom wil je uitvoer comprimeren, uitgaande van HTTPS wordt dat als onveilig gezien?
Als ik het goed begrijp is het probleem data-afhankelijk, verdwijnt het probleem na het aanpassen met die regel in php.ini, heb je het alleen op productie.
Het log is waarschijnlijk dat van Apache.
De tweede foutmelding wordt op internet geassocieerd met een FCGI time-out. Wat zijn de verschillen in configuratie van de webserver in productie en test? En kan je kijken wat de maximale grootte is van de (gedecomprimeerde) data die zlib moet uitpakken? Het kan zijn dat het groter wordt dan het beschikbare geheugen, misschien dat dat de oorzaak is?
Links:
https://stackoverflow.com/questions/33375823/apache-proxfy-fcgi-error-dispatching-request-to
https://serverfault.com/questions/1042034/what-is-the-origin-of-zlibs-zlib-error-2-deflating-data
Als ik het goed begrijp is het probleem data-afhankelijk, verdwijnt het probleem na het aanpassen met die regel in php.ini, heb je het alleen op productie.
Het log is waarschijnlijk dat van Apache.
De tweede foutmelding wordt op internet geassocieerd met een FCGI time-out. Wat zijn de verschillen in configuratie van de webserver in productie en test? En kan je kijken wat de maximale grootte is van de (gedecomprimeerde) data die zlib moet uitpakken? Het kan zijn dat het groter wordt dan het beschikbare geheugen, misschien dat dat de oorzaak is?
Links:
https://stackoverflow.com/questions/33375823/apache-proxfy-fcgi-error-dispatching-request-to
https://serverfault.com/questions/1042034/what-is-the-origin-of-zlibs-zlib-error-2-deflating-data
Er zijn geen verschillen, en ik doe niks met zlib() functies. Dus de error komt uit het zlib proces.
En waarom? Geen idee.
De instellingen tussen de productie en testomgeving zijn gewoon gelijk.
Zlib aanzetten in php.ini verhelpt ironisch gezien de error.
Ik kan memory-limit eens hoger zetten, maar wel opvallend is dat het met een kleine result-set gebeurt, terwijl ik vele grotere heb, plus dat ze nog eens netjes worden voorzien van off-set. Dus infeite lijkt het mij verwaarloosbaar.
En waarom? Geen idee.
De instellingen tussen de productie en testomgeving zijn gewoon gelijk.
Zlib aanzetten in php.ini verhelpt ironisch gezien de error.
Ik kan memory-limit eens hoger zetten, maar wel opvallend is dat het met een kleine result-set gebeurt, terwijl ik vele grotere heb, plus dat ze nog eens netjes worden voorzien van off-set. Dus infeite lijkt het mij verwaarloosbaar.
Gewijzigd op 16/03/2021 20:26:42 door - Ariën -
Als er geen verschillen zijn, hoe verklaar je dan dat het op productie fout gaat?
(En wat bedoel je met off-set?)
Richtingen waar ik zo even aan moet denken:
- gaat het elke keer op hetzelfde punt fout? zo nee, wat zijn de andere punten?
- indien niet elke keer: op welke momenten wel?
- gaat het elke keer bij dezelfde gebruiker mis?
- in hoeverre kan traffic hier mee te maken hebben?
- staat er meer opmerkelijks in het log van de webserver?
- draaien er meer processen op de VPS die van invloed kunnen zijn? (denk PHP TS vs. PHP NTS, I/O, ...)
- heb je mogelijkheid om gedetailleerdere logging aan te zetten?
- wat staat er in logbestanden van gerelateerde processen, of systeemlogging?
Misschien kan je (een stukje van) de code delen waar het (elke keer) foutgaat?
(En wat bedoel je met off-set?)
Richtingen waar ik zo even aan moet denken:
- gaat het elke keer op hetzelfde punt fout? zo nee, wat zijn de andere punten?
- indien niet elke keer: op welke momenten wel?
- gaat het elke keer bij dezelfde gebruiker mis?
- in hoeverre kan traffic hier mee te maken hebben?
- staat er meer opmerkelijks in het log van de webserver?
- draaien er meer processen op de VPS die van invloed kunnen zijn? (denk PHP TS vs. PHP NTS, I/O, ...)
- heb je mogelijkheid om gedetailleerdere logging aan te zetten?
- wat staat er in logbestanden van gerelateerde processen, of systeemlogging?
Misschien kan je (een stukje van) de code delen waar het (elke keer) foutgaat?
Het gaat steeds op hetzelfde punt fout, op een bepaalde resultset bij een bepaalde gebruiker, die net als de op de test-site php-fpm draait. met off-set bedoel ik de OFFSET functie in MySQL waarmee ik records over meerdere pagina's splits. Dus elke result zal haast even groot zijn.
De code kan ik geven,maar dat is wat gewoon een standaard query, en foreach die niet zo speciaal zijn in een legacy code. Gezien het op een enkele result fout gaat, lijkt het mij niet aan de code te liggen.
De enige opmerkelijke dingen wat ik tot nu toe gevonden heb waren de genoemde errors. Als ik erop Google kom ik een soortgelijk probleem tegen en andere zoekresultaten op Google zijn niet relevant is omdat het met Python te maken heeft. En echte oplossing was er niet echt....
Ik gok op een heel exotische bug in combinatie met mijn webserver-setup.
Een klein gokje is misschien dat Cloudflare misschien iets raars kan doen (geen idee hoe gzip precies werkt), of ik moet de memory-limit opschroeven, of ik moet PHP/Apache even updaten.
Update 2:
Ik zie wel dat mijn script wat error genereert van een lege array waar ik geen check met is_array doe, wat ook een oorzaak kan zijn. Ik ga deze week eens verder op onderzoek uit.
De code kan ik geven,maar dat is wat gewoon een standaard query, en foreach die niet zo speciaal zijn in een legacy code. Gezien het op een enkele result fout gaat, lijkt het mij niet aan de code te liggen.
De enige opmerkelijke dingen wat ik tot nu toe gevonden heb waren de genoemde errors. Als ik erop Google kom ik een soortgelijk probleem tegen en andere zoekresultaten op Google zijn niet relevant is omdat het met Python te maken heeft. En echte oplossing was er niet echt....
Ik gok op een heel exotische bug in combinatie met mijn webserver-setup.
Een klein gokje is misschien dat Cloudflare misschien iets raars kan doen (geen idee hoe gzip precies werkt), of ik moet de memory-limit opschroeven, of ik moet PHP/Apache even updaten.
Update 2:
Ik zie wel dat mijn script wat error genereert van een lege array waar ik geen check met is_array doe, wat ook een oorzaak kan zijn. Ik ga deze week eens verder op onderzoek uit.
Gewijzigd op 16/03/2021 23:23:18 door - Ariën -
Met even sparren kom je soms al verder.
Ben benieuwd naar de afloop.
Ben benieuwd naar de afloop.
Ik was er ook benieuwd naar..... alleen liep het uit tot een anti-climax.. :'(
Wil ik het debuggen, krijg ik het niet meer gereproduceerd. Statisch verwerkt hij de HTML-code gewoon, dus daarmee is niks mis. En het dynamisch werkt het PHP-script ook gewoon zoals het hoort.
Geen idee wat er mis was... :S
- Zou het te maken kunnen hebben met Cloudflare en een eventuele overdracht (handshake) tussen client-server-client wat niet lekker soepel verloopt? Ik weet niet of zlib hierin invloed kan hebben, het is een zomaar iets wat bij me in mij opkwam. Ik weet dat Cloudflare zelf ook al zlib gebruikt. Dus het feit dat het in mijn configuratie uitstond, maakte het al vreemd dat ik alsnog die errors in de log tegenkwam.
- Of was het misschien wat rotzooi in de /tmp waar die over struikelde, en wat inmiddels gepurged is?
Volgende keer maar direct de trukendoos openen als het gebeurt...
Wil ik het debuggen, krijg ik het niet meer gereproduceerd. Statisch verwerkt hij de HTML-code gewoon, dus daarmee is niks mis. En het dynamisch werkt het PHP-script ook gewoon zoals het hoort.
Geen idee wat er mis was... :S
- Zou het te maken kunnen hebben met Cloudflare en een eventuele overdracht (handshake) tussen client-server-client wat niet lekker soepel verloopt? Ik weet niet of zlib hierin invloed kan hebben, het is een zomaar iets wat bij me in mij opkwam. Ik weet dat Cloudflare zelf ook al zlib gebruikt. Dus het feit dat het in mijn configuratie uitstond, maakte het al vreemd dat ik alsnog die errors in de log tegenkwam.
- Of was het misschien wat rotzooi in de /tmp waar die over struikelde, en wat inmiddels gepurged is?
Volgende keer maar direct de trukendoos openen als het gebeurt...
Je had het over dat het misschien een bekende bug zou kunnen zijn.
Nu ken ik niet alle ins en outs van jouw situatie, je zou het beste zelf nog even kunnen grasduinen in de details:
https://bugs.php.net/search.php?cmd=display&search_for=zlib&x=0&y=0
Voor de rest maar hopen dat het niet nog een keer voorkomt?
Nu ken ik niet alle ins en outs van jouw situatie, je zou het beste zelf nog even kunnen grasduinen in de details:
https://bugs.php.net/search.php?cmd=display&search_for=zlib&x=0&y=0
Voor de rest maar hopen dat het niet nog een keer voorkomt?




