[MySQL/PHP] Te veel gegevens/Geen resultaten

[lemonade]

Ik heb een structureel probleem met de configuratie van mijn webserver.
Als een query een bepaald aantal records op moet halen (rond de 3500) dan geeft hij geen resultaten omdat dit er te veel zijn, er zal dus een buffer te klein zijn of iets dergelijks?
Alles werkt dus prima totdat er blijkbaar 'te veel' records in de tabel zitten.

Heeft iemand hier een oplossing/oorzaak voor?

Na zoeken op php.net en mysql.com ben ik niet veel wijzer geworden..

Edit: Ik heb nu tijdelijk een LIMIT in de query gezet, maar heeft iemand een structurele oplossing hiervoor?

[ Voor 13% gewijzigd door lemonade op 26-07-2005 11:45 ]

[Creepy]

Het lijkt me sterk dat het aan je server ligt want 3500 records is helemaal niet veel. Qua geheugengebruik kan dit ook niet veel zijn tenzij je gigantische blobs per record bijhoudt.
Ik gok erop dat het probleem in je code zit die de records ophaalt en verwerkt maar met de informatie die je ons nu geeft blijft dat allemaal giswerk. Als je iets specifieker je probleem kan uitleggen inclusief relevante (dus niet alle ) code dan graag

Zie ook P&W FAQ - De "quickstart"

[Verwijderd]

Gaat het soms om een MATCH query? Want dan krijg je al gauw een leeg resultaat, als je zoekresultaat meer dan 50% van de records omvat.

[lemonade]

Tis een vrij simpele query met normale hoeveelheid gegevens per record.
Het probleem bestaat server-breed dus het ligt niet aan 1 script, het heeft dus ook geen zin om de query hier te posten.

Misschien dat iemand hier iets aan heeft; Als ik van de SELECT * bv SELECT naam, woonplaats etc van maak, werkt de query weer iets langer, totdat ook deze geen resultaten meer geeft.

[Creepy]

En heb je de server logs al gecheckt? Wat melden die? Is die server misschien erg druk en is er zoveel geheugen + swap in gebruik zodt er geen ruimte meer is om de query in het geheugen te plaatsen?

[T-MOB]

Wat je kunt proberen om een ubuffered query uit te voeren. Wat Creepy hierboven zegt blijft echter staan. Het is uiterst vreemd dat de boel met 3500 records al vast loopt. Maak je verder wel gebruik van indexen?

[lemonade]

De logs van de server zijn meer dan 2.2 Gb, daar heb ik dus een dagtaak aan om die te controleren..Niet echt een optie dus.

De server heeft een normale belasting, daar zal het niet aan liggen.

Waar kan ik het beste een index op plaatsen? Deze staat nu op het meest geselecteerde veld..

[ Voor 28% gewijzigd door lemonade op 26-07-2005 14:06 ]

[T-MOB]

lemonade schreef op dinsdag 26 juli 2005 @ 14:06:
Waar kan ik het beste een index op plaatsen? Deze staat nu op het meest geselecteerde veld..

Indexen plaats je het best op velden waarop je condities toepast. De velden die terugkomen in je JOINS en WHERE clauses dus. Een willekeurige tutorial met wat uitgebreidere informatie over MySQL optimalisatie is hier te vinden.

[Creepy]

lemonade schreef op dinsdag 26 juli 2005 @ 14:06:
De logs van de server zijn meer dan 2.2 Gb, daar heb ik dus een dagtaak aan om die te controleren..Niet echt een optie dus.

Right. Je hoeft ook niet ALLE logs door te spitten, alleen die van het moment dat het mis gaat. Hier staat zeer waarschijnlijk het probleem in. Dus nogmaals: check die logs, dat is altijd een optie, en geeft je een stuk meer informatie dan domweg speculeren waar het eventueel aan zou kunnen liggen.
Alleen als het hier niet in zit, is het een probleem aan de kant die jouw code uitvoert, of een probleem in je code. Als je logs wel iets melden is meteen helemaal duidelijk wat er mis gaat

[Gwaihir]

Ja; voer die query uit en vraag gelijk daarna de logs op -> hoef je niet meer dan de laatste minuut te bekijken. Logisch toch?

Kun je die dagtaak besteden aan het instellen van de maximum grootte van die logs

[lemonade]

Ik zal eens even een poging wagen aan de logs..ik hoop dat ze veel te melden hebben..
En ja aan die logfile size mag wat gebeuren..

[Gomez12]

is het niet gewoon de max_execution_time van php die op een waarde van 1 sec staat ofzo???