Bekijk Volledige Versie : query met te veel resultaten = error 500
Christophe1
07/04/09, 22:39
Ik stel vast dat wanneer een query meer dan ongeveer 6500 records teruggeeft, ik een error 500 krijg.
Gaat hier om een up-to-date da-server (mysql, suphp, apache)
Een out-of-memory issue?
Al veel gegoogled, gespeeld met my.cnf en php.ini, maar ik geraak er niet uit.
Server heeft een gemiddelde load < 0.1 (2 cpu's), dus 't is niet dat ik ergens tegen hardware limieten ofzo kom.
Iemand suggesties? Welke waarden kan ik verhogen om toch query's te kunnen laten draaien die zo'n 10000 records teruggeven?
Triloxigen
07/04/09, 23:15
Is het eventueel mogelijk om de query te posten?
Christophe1
07/04/09, 23:18
Dank je wel voor je snelle antwoord!
Gaat om een simpele:
$query = "SELECT * FROM contacten ORDER by naam, voornaam ASC";
Deze ging perfect tot er zo'n 6500 records in de database zaten. Plots doet ie 't nie meer en krijg ik een error 500... Verander ik de query zodat ie minder resultaten geeft; probleem opgelost.
Triloxigen
07/04/09, 23:27
Op zo'n query vastlopen is wel heel vreemd, het zal iig niet liggen dat de query niet optimaal is :o
Geen max. tijd van je php/apache process?
Probeer de query eens in phpMyAdmin. Dan weet je of het aan je script ligt of dat er toch iets in de database mis is...
Christophe1
08/04/09, 00:48
Goeie tip om het inderdaad eens in phpMyAdmin te proberen. Weten we idd direct of het een mysql of php probleem is...
In phpMyAdmin geen enkel probleem om de query uit te voeren. Duurde 0.02 seconden.
Ondertussen kwam ik erachter dat mijn wijzigingen in php.ini niks uitmaakten. Zelfs even engine op "off" zetten haalde niks uit. php bleef in dit geval gewoon z'n ding doen. Nochthans steeds netjes apache herstart na elke wijziging. Was ik misschien in de verkeerde php.ini bezig? Heb er nl. 3 gevonden:
/usr/local/etc/php5/cgi/php.ini
/usr/local/directadmin/custombuild/php-5.2.6/php.ini-recommended
/usr/local/directadmin/custombuild/php-5.2.6/php.ini-dist
In alle 3 even geprobeerd om engine op off te zetten om direct te kunnen zien welke de goeie is; maar bij geen van de 3 enig effect... Iemand suggesties? Want wellicht is het probleem op te lossen door php een beetje meer geheugen te geven.
Ik heb een custombuild installatie met php in cgi mode (suphp dus).
En Peter, nee; de max. tijd is het probleem niet. Ik krijg die error 500 onmiddelijk te zien. Niet na een time-out...
die error 500 gaat als je met suphp werkt ook gepaard met een log entry in je error_log
even in je error log kijken naar de exacte melding waardoor het fout loopt. Daar zou je normaal wel wijzer moeten van worden.
Christophe1
08/04/09, 20:13
Het ziet ernaar uit dat ik geen error_log meer heb. Staat nochthans in m'n php.ini dat ie effectief daar moet loggen. Nog een teken dat er op wijst dat die php.ini dus effectief niet gebruikt lijkt te worden...
Nochthans een vrij standaard custombuild server waarbij alles up-to-date is en verder eigenlijk alles prima werkt.
Anders even kijken in je phpinfo(); de locatie van php.ini staat in het bovenste blok.
Kijk je overigens ook in de juiste error log? Zie /var/log/httpd/domains/ en niet /var/log/httpd/error_log.
Christophe1
08/04/09, 20:33
Shame on me... Ik keek inderdaad in de verkeerde logs. Alweer veel bij geleerd, waarvoor dank!
Wat zie ik daar;
ModSecurity: Output filter: Response body too large (over limit of 524288, total not specified)
En via phpinfo() ook gezien dat de gebruikte php.ini deze is:
/usr/local/etc/php5/cgi/php.ini
Wel vreemd dat wanneer ik in die file bv engine = On verander naar engine = Off en vervolgens apache herstart, alles doodleuk blijft draaien?
Enig idee waar ik die limiet van 524288 (bytes?) kan verhogen?
Super bedankt trouwens allemaal voor de hulp!
Christophe1
08/04/09, 20:53
Nevermind, probleem opgelost!
Super bedankt allemaal om me op weg te helpen!!
De oplossing:
In /etc/modsecurity/modsecurity-rules-selected-by-web4host.net.conf
op zoek gaan naar SecResponseBodyLimit om de waarde ernaast te verhogen.
Even apache herstarten en klaar :)
Ik las je topic en mijn 1e vermoeden was modsecurity, goed dat het is opgelost.