mysql buffer voll?

[ragnar]

Hi @ all

Ich habe eine DB mit ca. 120 Adressdatensätzen. Jeder Benutzer hat in dieser Tabelle 12 Felder mit Angaben wie (Strasse, Plz, Tel, email...etc) Ich mache eine SELECT DISTINCT * FROM 'personen' WHERE kanton='Bern' Abfrage, was auch klappt, solange es nicht zuviele Datensätze sind, die zutreffen. Wenn mehr als 16 Adressen ausgemacht werden, kommt die Meldung: Diese Seite kann nicht mehr angezeigt werden (404). Ich muss die SELECT Abfrage mit "LIMIT 16" ergänzen, so kann ich den Error (404) umgehen. In diesem Fall werden aber nur 16 Datensätze angezeigt, was nicht der effektiven Anzahl entspricht (Etwa 40+).
Ich denke das liegt an dem Buffer oder sonst irgend einem Speicher... Wie kann ich diesen erhöhen? Wisst ihr um welchen speicher es sich handeln könnte?
PS ich mache eine While abfrage mit PHP...gibt es dort etwa auch limits?

Vielen Dank und Gruss
Ragnar

[Mark]

hi,

das liegt nicht an mysql bzw deiner datenbank sondern an deinem programm. poste mal bisschen quelltext von deinem prog, dann kann man dir hier im forum helfen.

[Tom]

Hello,

Ich habe eine DB mit ca. 120 Adressdatensätzen. Jeder Benutzer hat in dieser Tabelle 12 Felder mit Angaben wie (Strasse, Plz, Tel, email...etc) Ich mache eine SELECT DISTINCT * FROM 'personen' WHERE kanton='Bern' Abfrage, was auch klappt, solange es nicht zuviele Datensätze sind, die zutreffen. Wenn mehr als 16 Adressen ausgemacht werden, kommt die Meldung: Diese Seite kann nicht mehr angezeigt werden (404).

Woher kommt denn die Fehlermeldung?
MySQL gibt an den Browser nicht selbsttätig Fehlermeldungen aus. Die muss man schon selber aus dem Resultset (das ist dann false) und der Fehlerschnittstelle (mysql_error() und mysql_errno() http://de2.php.net/manual/de/function.mysql-errno.php ) herausholen.

Nichtsdestotrotz (tolles Wort, oder *g*) solltest Du genau darauf achten, dass Deine Scripte nach einer Abfrage auch das Resultset wieder frei geben
mysql_free_result() http://de2.php.net/manual/de/function.mysql-free-result.php, da es sonst bis zur Freigabe der Connection (spätestens am Scriptende) auf dem Datanbankseerver bleibt, und das meistens nutzlos.

Ich muss die SELECT Abfrage mit "LIMIT 16" ergänzen, so kann ich den Error (404) umgehen. In diesem Fall werden aber nur 16 Datensätze angezeigt, was nicht der effektiven Anzahl entspricht (Etwa 40+).
Ich denke das liegt an dem Buffer oder sonst irgend einem Speicher... Wie kann ich diesen erhöhen? Wisst ihr um welchen speicher es sich handeln könnte?
PS ich mache eine While abfrage mit PHP...gibt es dort etwa auch limits?

Kommt der Fehler vor oder während der Ausgabe der Datensätze?

Werden die Datensätze während oder nach dem Auslesen des Resultsets ausgegeben?

Liebe Grüße aus http://www.braunschweig.de

Tom

[ragnar]

Thanks for the request!

@tom

Woher kommt denn die Fehlermeldung?

Also es ist leider gar keine Fehlereldung, sondern einfach nur die Browser (IE) Fehlermeldung 404...

Nichtsdestotrotz (tolles Wort, oder *g*) solltest Du genau darauf achten, dass Deine Scripte nach einer Abfrage auch das Resultset wieder frei geben »» mysql_free_result()

Ist im Script bereits enthalten.

Kommt der Fehler vor oder während der Ausgabe der Datensätze?

Die Fehler treten vor der Ausgabe der Datensätze auf!

Werden die Datensätze während oder nach dem Auslesen des Resultsets ausgegeben?

Die Datensätze werden in der while schleife ausgegeben (denke ich)....

@Mark

Es könnte natürlich auch ein php-script Fehler sein...leider habe ich den Code nicht bei mir...werde ihn am Abend posten.

Wie viel kann in einer while-schleife gebuffert werden?
Addieren sich die Daten bei jedem durchlauf, bis zum Ende -> danach werden sie weitergeleitet? oder werden sie bei jedem durchlauf weitergeleitet? (PHP technische Frage)

vielen Dank
grüsse Ragnar

[Tom]

Hello,

Woher kommt denn die Fehlermeldung?
Also es ist leider gar keine Fehlereldung, sondern einfach nur die Browser (IE) Fehlermeldung 404...

Na, dann überlegen wir doch mal gemeinsam, warum 404 (Resource not found) ausgelöst werden kann?

1. Das Script ist überhaupt nicht an der vermuteten Stelle vorhanden
2. Beim Hochladen wurden Groß-/Kleinschreibung missachtet / zerstört
3. Das Script hat versehentlich eine andere Extension erhalten
(4. Die Zugriffsrechte reichen nicht aus, aber da käme dann 403 - Forbidden)

Nun Ragnar, musst Du dich entscheiden...

Liebe Grüße aus http://www.braunschweig.de

Tom

[ragnar]

Nun Ragnar, musst Du dich entscheiden...

Ich glaube das keiner der Fälle zutrifft!
aso meine Abfrage wird anhand einer ID ausgelöst...
index.php?kantid=6 (enthält 8 Einträge)...welche problemlos aufgelistet werden. mit index.php?kantid=7 (enthält 40 Einträge) geht nix mehr => 404. Es muss irgend ein Fehler zwischen der kommunikation von PHP mit dem Browser sein. oder?

greets ragnar

[Ilja]

yo,

ich habe nicht besonders viel ahnung von browser fehlermeldungen. aber ich vermute mal, beim übertragen von seite zu seite benutzt du den get mode und deine daten sind zu gross dafür. nur so eine vermutung, aber ich kann dort ganz falsch liegen.

Ilja

[Tom]

Hello,

Nun Ragnar, musst Du dich entscheiden...
Ich glaube das keiner der Fälle zutrifft!
aso meine Abfrage wird anhand einer ID ausgelöst...
index.php?kantid=6 (enthält 8 Einträge)...welche problemlos aufgelistet werden. mit index.php?kantid=7 (enthält 40 Einträge) geht nix mehr => 404. Es muss irgend ein Fehler zwischen der kommunikation von PHP mit dem Browser sein. oder?

Jein. Das ist ein Problem zwischen dem Browser und dem Webserver. Bei PHP kommt der Request gar nicht erst an. Oder hast Du eine Umleitung in PHP programmiert? Dann könnte es ja auch schon ein Folgefehler sein.

404 ist "Resource not found" und das bekommt man immer dann, wenn die URL nicht vorhanden oder nicht auffindbar ist.

Ist das Projekt denn schon öffentlich? Dann könnten wir da auch mal versuchen, aufzurufen. Wo wird denn hosted? Ist das ein eigener Webserver? Funktionieren ganz "normale" Seitenaufrufe auf reine HTML-Seiten noch ordnungsgemäß?

Liebe Grüße aus http://www.braunschweig.de

Tom

[Sven Rautenberg]

Moin!

Nichtsdestotrotz (tolles Wort, oder *g*) solltest Du genau darauf achten, dass Deine Scripte nach einer Abfrage auch das Resultset wieder frei geben
mysql_free_result() http://de2.php.net/manual/de/function.mysql-free-result.php, da es sonst bis zur Freigabe der Connection (spätestens am Scriptende) auf dem Datanbankseerver bleibt, und das meistens nutzlos.

Nö, das dürfte absolut unproblematisch sein.

PHP schiebt die Datenbank-Ergebnisse mit dem Befehl mysql_query() komplett in einen PHP-eigenen Zwischenspeicher und liefert von dort aus dann die Datensätze aus. Die Datenbank ist schon direkt nach mysql_query() mit der Abfrage fertig und speichert außer der noch bestehenden Verbindung nichts mehr.

Wenn PHP mit der Größe des Datensatzen nicht klarkommt, hilft kein mysql_free_result(), weil das ja erst _nach_ der kompletten Ausgabe aufgerufen werden dürfte (vorher würde es die abgefragten Datensätze löschen). Wenn zu viele Datensätze ausgelesen werden müssen, als PHP Speicher kriegen kann, dann würde sich mysql_unbuffered_query() anbieten. Das dürfte aber wirklich nur interessant sein, wenn man als Ergebnis mehrere Gigabyte an Daten erwartet. Und solche Monsterabfragen sind gewöhnlicherweise nicht zu erwarten - jedenfalls definitiv nicht bei 40 Datensätzen, die man per DISTINCT erhält.

Ich muss die SELECT Abfrage mit "LIMIT 16" ergänzen, so kann ich den Error (404) umgehen. In diesem Fall werden aber nur 16 Datensätze angezeigt, was nicht der effektiven Anzahl entspricht (Etwa 40+).

Benutze mal einen anderen Browser, als nur den IE. Der zeigt nämlich leider eine selbstgenerierte Fehlermeldung an, und nicht das, was der Server tatsächlich gesendet hat. Ob es sich tatsächlich um einen 404-Fehler handelt, oder ob sich das der IE nur ausgedacht hat, ist noch zu klären.

- Sven Rautenberg

[Tom]

Hello,

Nichtsdestotrotz (tolles Wort, oder *g*) solltest Du genau darauf achten, dass Deine Scripte nach einer Abfrage auch das Resultset wieder frei geben
mysql_free_result() http://de2.php.net/manual/de/function.mysql-free-result.php, da es sonst bis zur Freigabe der Connection (spätestens am Scriptende) auf dem Datanbankseerver bleibt, und das meistens nutzlos.

Nö, das dürfte absolut unproblematisch sein.

PHP schiebt die Datenbank-Ergebnisse mit dem Befehl mysql_query() komplett in einen PHP-eigenen Zwischenspeicher und liefert von dort aus dann die Datensätze aus. Die Datenbank ist schon direkt nach mysql_query() mit der Abfrage fertig und speichert außer der noch bestehenden Verbindung nichts mehr.

Wo steht das?

Freigeben muss man aber trotzdem mal was, egal von wem der Speicher vollgemüllt wird. Insbesondere, wenn man das Query in einer Funktion aufruft, muss man vor dem Ende der Funktion die Rückgabe des Handles veranlassen, es sei denn, dass man es vererbt / weiterreicht.

Wenn man natürlich nur Miniscripte mit einer einzigen Query schreibt, ist das uninteressant.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Sven Rautenberg]

Moin!

PHP schiebt die Datenbank-Ergebnisse mit dem Befehl mysql_query() komplett in einen PHP-eigenen Zwischenspeicher und liefert von dort aus dann die Datensätze aus. Die Datenbank ist schon direkt nach mysql_query() mit der Abfrage fertig und speichert außer der noch bestehenden Verbindung nichts mehr.

Wo steht das?

Im Manual.

Freigeben muss man aber trotzdem mal was, egal von wem der Speicher vollgemüllt wird. Insbesondere, wenn man das Query in einer Funktion aufruft, muss man vor dem Ende der Funktion die Rückgabe des Handles veranlassen, es sei denn, dass man es vererbt / weiterreicht.

Je Verbindung zur Datenbank gibt es einen dafür reservierten, größenmäßig nicht festgelegten Pufferbereich, in dem jeweils die Abfrageergebnisse zwischengespeichert werden (natürlich nur, wenn es ein Ergebnis gibt, was man mit mysql_fetch_array() o.ä. abfragen kann).

Entweder braucht man, weil man eine wirklich riesige Ergebnisausgabe hat, den Speicher tatsächlich für andere Aufgaben - dann macht ein zwischenzeitliches Freigeben des Puffers nach der Abfrage vielleicht Sinn.

Wenn man natürlich nur Miniscripte mit einer einzigen Query schreibt, ist das uninteressant.

Sicherlich.

- Sven Rautenberg

[Tom]

Hello,

Wo steht das?

Im Manual.

Danke :-)

http://de2.php.net/manual/de/function.mysql-unbuffered-query.php
Bei mysql_query() stand es leider nicht vernünftig. Das Ausgaben "gepuffert" werden, sagt ja leider nichts darüber aus, wo. Habe ich doch glatt wieder was gelernt.

Gibt es dann für mysql_num_rows() eine andere Möglichkeit, oder muss man da vorher ein count absetzen an MySQL? Lohnt sich das ggf., bei höherer Datenbanklast und "Geradeausabfragen" auf die unbufferd query umzusteigen?

Liebe Grüße aus http://www.braunschweig.de

Tom

[Sven Rautenberg]

Moin!

Gibt es dann für mysql_num_rows() eine andere Möglichkeit, oder muss man da vorher ein count absetzen an MySQL? Lohnt sich das ggf., bei höherer Datenbanklast und "Geradeausabfragen" auf die unbufferd query umzusteigen?

Ich kann insbesondere aus den zusätzlichen Anmerkungen für unbuffered Query nicht erkennen, dass man damit irgendeinen wirklichen sinnvollen Vorsprung herausarbeiten könnte - außer bei wirklich großen Datenabfragen, die man wirklich komplett ausgeben will.

Im Web-Kontext will man das aber nicht wirklich.

Alleine schon die Anmerkung, dass man den kompletten Datenbankserver - bzw. zumindest die abgefragten Tabellen - durch eine noch nicht komplett abgeholte Datenbankabfrage für Schreibzugriffe blockieren kann, sollte einem zu denken geben.

- Sven Rautenberg

[Tom]

Hello,

Alleine schon die Anmerkung, dass man den kompletten Datenbankserver - bzw. zumindest die abgefragten Tabellen - durch eine noch nicht komplett abgeholte Datenbankabfrage für Schreibzugriffe blockieren kann, sollte einem zu denken geben.

Ja, das ist allerdings wahr. Dann ist der kleine Geschwindigkeitsvorteil, den man vielleicht bei der Ausgabe der Seite herausholt ruck zuck dahin. Web ist eben Quantisierungstechnik.

Wird wohl bei normalen Seiten auch nicht in Frage kommen, da ja auf der anderen Seite der Browser ggf. auch erst anzeigt, wenn die Seite vollständig da ist.

Haken wirs ab.

Liebe Grüße aus http://www.braunschweig.de

Tom