Massig SQL Error Emails vom Shop

[mizzy]

Hallo,

seit ich mit dem Shop online bin erhalte ich total Viele Emails vom Shop

in diesem Format:

mysql error: [2006: MySQL server has gone away] in EXECUTE

("UPDATE xt_sessions2 SET expiry = NOW() + INTERVAL 1440 SECOND

 ,expireref='', modified = NOW() WHERE /*! BINARY */ 

sesskey = 'c04d2d16aabbff612e1e238aXXXXXXXX' AND expiry >= NOW()")

Nur die Session-ID ist eine andere.

Mittlerweile 22 Emails innerhalb von nicht mal 2 Stunden.

Was ist das?

V.G. Micha

[SS156]

Die SQL-Abfrage war zu lang. Du musstest eventuell die maximale Paketgröße erhöhen: max_allowed_packet

gruß

kris

ps: bin mir da aber nicht 100% sicher......

[mizzy]

Kann die Abfrage denn nicht anders gestaltet werden? Das solche Fehler nicht auftreten können?

Hat das was damit zu tun, das in der dreier Version die Sessions in Daten geschrieben werden konnten (konnte man ja bei Installation auswählen) und in Veyton die Sessions immer in die DB geschrieben werden?

Hoster (all-inkl) ist da auch schon dran, aber ich vermute, der wird da soviel auch nicht ausrichten können.

V.G.

Micha

[mizzy]

Hallo,

folgende Meldung hat mir all-inkl.com dazu geschrieben:

permanente DB Verbindungen sind grundsätzlich schlecht. Ihnen stehen 25 gleichzeitig offene verbindungen zur verfügung, wenn nun 25 User im Shop sind ist bei permanenten DB Verbindungen Schluss weil diese ja die ganze Zeit offen gehalten werden. Ich empfehle Ihnen daher die sessionverwaltung auf Dateibasierend umzustellen.

Kann mir jemand was dazu sagen?

Benötigt der Shop wirklich für die Sessions Persistente Datenbankverbindungen???

V.G Micha

[mzanier]

Nein, es wird keine persistente Verbindung für die Session DB gemacht.

[Matthias]

Nein braucht er nicht, im Veyton gibt es die Option garnicht mehr.

Wobei 25 Verbindungen seitens des Hosters auch net gerade dolle sind.

[mizzy]

Danke für die schnellen Antworten

In dem Fall sollte es ja aber egal sein wie viele Verbindungen der Hoster zulässt.

Ich werden das mal weiterleiten das der Shop keine persistente Verbindung nutzt. Mal schauen

V.G.

Micha

[mizzy]

Hallo,

also all-inkl. hat mir nun folgendes mitgeteilt:

Die Techniker haben nun auf die Datenbank 3 Indizes gesetzt auf:

ALTER TABLE `xt_products` ADD INDEX `all_inkl_manufacturers_id` (`manufacturers_id` ) ;

ALTER TABLE `xt_orders_products` ADD INDEX `all_inkl_orders_id` (`orders_id` );

ALTER TABLE `xt_orders_products` ADD INDEX `all_inkl_products_quantity` (`products_quantity` );

Informationen zu Indizes finden Sie unter folgendem Link:

http://dev.mysql.com/doc/refman/5.1/de/multiple-column-indexes.html

Dies sollte zur Entlastung und Verbesserung der MySQL Abfragen führen. Diese können jedoch jederzeit wieder gelöscht werden. 150 Kunden auf einem Shop sind auch in kleineren Tarifen problemlos möglich. Die Auslastung hier muss also andere Ursachen haben. Ebenso wird der von Ihnen genutzte Shop auch von anderen Usern genutzt. Die Begrenzung von 25 gleichzeitigen Datenbank Abfragen sollte hier auch keine Probleme verursachen da bei ordnunsggemäßer Programmierung die Datenbank Abfragen nach Nutzung wieder geschlossen werden. Bitte testen Sie einmal ob nach dem Setzen der Indizes das Problem behoben wurde.

Also was soll mir gesagt werden?

So recht verstehe ich das nicht mit den Indizies.

Und ich versteh auch nicht so ganz warum wieder von den 25 gleichzeitigen Datenbankabfragen gesprochen wird. Ich dachte der Shop nutzt keine persistente Verbindung.

V.G. Micha

PS: Nachtrag, scheinbar hat auch das nichts genutzt. Denn die Datenbankfehleremails des Shops kommen weiterhin. Und dieses Mal habe ich den selbst mal absichtlich verursacht. Das geht indem man einfach mal sich anmeldet, nen Produkt in den Warenkorb legt und dann mal so 10 bis 15 Minuten nichts macht, z.B. wo anders surfen oder Emails schreiben. Dann geht man mal wieder in den Shop, will auf den Warenkorb klicken bzw. Bestellvorgang einleiten und was muss ich da sehen, es sind auf einmal keine Artikel mehr im Warenkorb weil die Session gelöscht wurde. Auch bin ich gleich nicht mal mehr eingeloggt.

Aber jetzt zum eigentlich komischen:

Log ich mich aus, aus dem Shop mach Firefox zu und log mich wieder ein, ist doch glatt der Warenkorb wieder da, der vorher weg war.

Also woran liegt das nun am Shop oder am Hoster? Wobei ich aufgrund meiner Fehlersuche fast denke, dass das Problem Shopseitig besteht.

Zumal ja all-inkl. nicht irgendso ne Billighoster Schmiede ist :-) Zumindest nicht der Business Tarif.

[mizzy]

So noch einmal neues vom Hoster:

in der Datei ./xtFramework/library/adodb/drivers/adodb-mysql.inc.php wurden noch mysql_pconnects verwendet diese haben wir einmal abgeändert.

Desweiteren haben wir noch 2 Indizes gesetzt die aus der Analyse des Slowqueries.logs

ALTER TABLE `xt_plugin_products` ADD INDEX ( `plugin_status` )

ALTER TABLE `xt_languages` ADD INDEX ( `sort_order` )

V.G. Micha

[mzanier]

ja in der datei gibt es eine funktion für den pConnect, aber die wird vom shop nicht verwendet

sowohl die verbindung zur shopdatenbank und die verbindung zur session datenbank fahren mit einem normalen connect, und keinen pconnect.

[mizzy]

So, also der Hoster macht jetzt nichts mehr, er ist der Meinung das ist eine Sache für die Shopprogrammierer, da dies am Shop liegt.

Muss natürlich sagen, das die Änderung an der

./xtFramework/library/adodb/drivers/adodb-mysql.inc.php

scheinbar was gebracht hat. Das teste ich gerade. -->

Nachtrag hat nichts gebracht. SQL Error besteht weiter und Sessions werden nach gewisser Zeit des nichts tun einfach gelöscht!

Es ist nur verwunderlich das der Shop bei Hosteurope in irgendwelchen Billigtarifen läuft, aber bei etwas teurerer Tarifen wie ich ihn bei All-inkl.com hab, bei längeren Sitzungen einfach immer die Datenbank abschmiert und die Session einfach weg ist. Aber nach erneuten Einloggen ist der Warenkorb wieder da.

Bin echt ratlos.

V.G. Micha

[mizzy]

Also noch mal ich.

Mein Hoster (all-inkl.com) ist weiterhin der Meinung das es am Shop liegt und Datenbankverbindungen nicht geschlossen werden von Scripten und dies den Fehler verursacht

Anbei noch einmal die Antwort:

Zum Fehler ist noch zu sagen das die Datenbank nicht defekt ist sondern die Anzahl der maximalen parallelen DB Verbindungen erreuicht wurde. Dieser Wert steht momentan bei 25. Die Tatsache das die Meldung auch kommt wenn wenig Betrieb auf den Seiten ist deutet eher darauif hin das eine benutzte DB Verbindung nicht wieder vom Script geschlossen wird wie es in sekundenbruchteilen üblich ist sondern noch offenbleibt. Diese offenen Verbindungen zählen dann natürlich bei den Userconnections mit und wenn 25 Stück erreicht sind erscheint die Meldung. Die 25 ist ein Standardwert bei uns. Daher stellt sich die Frage ob der Shop eventuell speziell mit SCripten erweitert wurde die DB-Verbindungen nicht schließen oder andere Scripte neben dem Shop zur DB Connecten.

Die gleichzeitigen DB Verbindungen können Sie aber gar nicht vermeiden da ja Scripte auch parallel aufgerufen werden können.

Stimmen Sie dem Uzug auf einen modernern Server zu? Wie gesagt sind die 25 Verbindungen bei uns Standard und alle System laufen damit. Wenn der Shop auch bei wenigen Besuchern die Meldung bringt kann es sein das DB-Verbindungen offen bleiben, ob persistene Connects oder nicht. Durch den Umzug auf einen modernen Server soll ausgeschlossen werden das der DB-Server zu langsam antwortet.

V.G. Micha

[mzanier]

das wäre dann aber eine serversache.

Wir verwenden adodb als DB library, verbindungen werden von PHP selbst nach scriptende geschlossen.

Funktioniert ja auch auf jedem anderen Hoster. (sogar 1&1 und Strato ).

[mizzy]

das wäre dann aber eine serversache.

Wir verwenden adodb als DB library, verbindungen werden von PHP selbst nach scriptende geschlossen.

Funktioniert ja auch auf jedem anderen Hoster. (sogar 1&1 und Strato ).

Das Sessionhandling ist aber m.E. nicht Provider Sache. Bei Verlängerung der Session entsteht ja der DB Fehler. Die Session wird einfach gekillt. Das passiert ja selbst wenn nur ein User im Shop ist.

[mizzy]

Hallo,

mein Provider war nun so nett mich über nacht auf einen neuen Server zu schieben. Das Problem tritt leider weiter auf.

Hab auch noch folgenden Hinweis zu der Fehlermeldung gefunden.

Die SQL-Abfrage war zu lang. Du musst die maximale Paketgröße erhöhen oder die Abfrage aufteilen. Das tritt z.B. oft bei Imports auf, die alle Daten in einer einzigen INSERT-Abfrage haben.

Bin nun echt etwas ratlos.

Aber scheen is das nicht wenn der Kunde was in Warenkorb legt und dann ist irgendwann die Session weg, nur weil der Kunden ne zeitlang nichts im Shop geklickt hat. Das müsste sich doch irgendwie beheben lassen, oder?

V.G. Micha

[mzanier]

Das Sessionhandling ist aber m.E. nicht Provider Sache. Bei Verlängerung der Session entsteht ja der DB Fehler. Die Session wird einfach gekillt. Das passiert ja selbst wenn nur ein User im Shop ist.

Die session wird aber nicht vom Shop gekillt, sondern diese wird vom Server gekillt.

-> Session garbage Collector nennt sich dies, und ist übe die php.ini einstellbar

Der Shop selbst, löscht keine Daten aus der session Tabelle, das wird vom Server angestoßen.

[Borlabs]

Wenn du bei 1und1 bist, die hatten die letzten Tage massive Probleme mit ihren DBs, die wollten die Auths nicht zulassen und daher kam des öfteren dieser Fehler.

[dvschuetz]

Hallo,

Ich hatte das Problem der massenhaften SQL-Errors auch schon, und zwar unter anderem auch bei jedem Kundenlogin.

Ich habe jetzt mal auf dem gleichen Server xt:c komplett neu in ein anderes Verzeichnis installiert, mit neuer Datenbank etc. ... OK, war echt viel Arbeit, aber:

Bis jetzt treten keine sql-error mehr auf.

Gruß Dietmar

[mizzy]

Wenn du bei 1und1 bist, die hatten die letzten Tage massive Probleme mit ihren DBs, die wollten die Auths nicht zulassen und daher kam des öfteren dieser Fehler.

all-inkl.com Business Tarif

1und1 geh mir weg

V.G. Micha

[jernst]

Hallo zusammen,

wir haben gleichen Provider (all-inkl.), und gleichen Fehler max_user_connections .........

Wie kann denn dies nun konkrte beseitigt werden? Neuinstalation in neuem Verzeichnis????

Gruß

J,. Ernst

[mschoen]

Im Ernst wenn es soviele Probleme gibt wechselt den Hoster...

[Leex]

gibt es zu diesem fehler bereits eine lösung? ... ist bei mir jetzt auch aufgetreten :/

[Leex]

keine lösung?!