General error: 1615 Prepared statement needs to be re-prepared

  • Betroffene Version
    WoltLab Suite 3.1

    Hey Leute!

    Das wird gefühlt in letzter Zeit immer schlimmer mit der Meldung "General error: 1615 Prepared statement needs to be re-prepared".

    Ich hoste schon Jahre bei Alfahosting, problemlos, funktioniert gut. Bisher. Genutzt wird der Business Webhosting Tarif.

    Die Meldung im Log sieht eigentlich fast immer gleich aus:

    Aufgerufene URL
    /
    Referrer
    https://www.!!!XYZ!!!.de/
    WoltLab Suite
    3.1.11
    PHP
    7.3.13
    Fehlermeldung
    Could not execute statement 'SELECT user_follow.* FROM wcf1_user_follow user_follow WHERE userID = ? '
    Art
    wcf\system\database\exception\DatabaseQueryExecutionException
    Datei (Zeile)
    /var/www/web29277955/html/!!!XYZ!!!/lib/system/database/statement/PreparedStatement.class.php (105)
    Query Parameter 1
    1
    Stacktrace
    1. /var/www/web29277955/html/!!!XYZ!!!/lib/data/DatabaseObjectList.class.php (195): wcf\system\database\statement\PreparedStatement->execute(…)
    2. /var/www/web29277955/html/!!!XYZ!!!/lib/data/user/follow/UserFollowerFriendsListAction.class.php (39): wcf\data\DatabaseObjectList->readObjects(…)
    3. [internal function] (?): wcf\data\user\follow\UserFollowerFriendsListAction->getFriends(…)
    4. /var/www/web29277955/html/!!!XYZ!!!/lib/data/AbstractDatabaseObjectAction.class.php (204): call_user_func(…)
    5. /var/www/web29277955/html/!!!XYZ!!!/lib/system/event/listener/FollowerFriendsListListener.class.php (21): wcf\data\AbstractDatabaseObjectAction->executeAction(…)
    6. /var/www/web29277955/html/!!!XYZ!!!/lib/system/event/EventHandler.class.php (144): wcf\system\event\listener\FollowerFriendsListListener->execute(…)
    7. /var/www/web29277955/html/!!!XYZ!!!/lib/system/event/EventHandler.class.php (177): wcf\system\event\EventHandler->executeInheritedActions(…)
    8. /var/www/web29277955/html/!!!XYZ!!!/lib/page/AbstractPage.class.php (141): wcf\system\event\EventHandler->fireAction(…)
    9. /var/www/web29277955/html/!!!XYZ!!!/lib/page/CmsPage.class.php (115): wcf\page\AbstractPage->assignVariables(…)
    10. /var/www/web29277955/html/!!!XYZ!!!/lib/page/AbstractPage.class.php (294): wcf\page\CmsPage->assignVariables(…)
    11. /var/www/web29277955/html/!!!XYZ!!!/lib/page/AbstractPage.class.php (114): wcf\page\AbstractPage->show(…)
    12. /var/www/web29277955/html/!!!XYZ!!!/lib/system/request/Request.class.php (83): wcf\page\AbstractPage->__run(…)
    13. /var/www/web29277955/html/!!!XYZ!!!/lib/system/request/RequestHandler.class.php (96): wcf\system\request\Request->execute(…)
    14. /var/www/web29277955/html/!!!XYZ!!!/index.php (9): wcf\system\request\RequestHandler->handle(…)
    Fehlermeldung
    SQLSTATE[HY000]: General error: 1615 Prepared statement needs to be re-prepared
    Art
    PDOException
    Datei (Zeile)
    /var/www/web29277955/html/!!!XYZ!!!/lib/system/database/statement/PreparedStatement.class.php (93)
    Stacktrace
    1. /var/www/web29277955/html/!!!XYZ!!!/lib/system/database/statement/PreparedStatement.class.php (93): PDOStatement->execute(…)
    2. /var/www/web29277955/html/!!!XYZ!!!/lib/data/DatabaseObjectList.class.php (195): wcf\system\database\statement\PreparedStatement->execute(…)
    3. /var/www/web29277955/html/!!!XYZ!!!/lib/data/user/follow/UserFollowerFriendsListAction.class.php (39): wcf\data\DatabaseObjectList->readObjects(…)
    4. [internal function] (?): wcf\data\user\follow\UserFollowerFriendsListAction->getFriends(…)
    5. /var/www/web29277955/html/!!!XYZ!!!/lib/data/AbstractDatabaseObjectAction.class.php (204): call_user_func(…)
    6. /var/www/web29277955/html/!!!XYZ!!!/lib/system/event/listener/FollowerFriendsListListener.class.php (21): wcf\data\AbstractDatabaseObjectAction->executeAction(…)
    7. /var/www/web29277955/html/!!!XYZ!!!/lib/system/event/EventHandler.class.php (144): wcf\system\event\listener\FollowerFriendsListListener->execute(…)
    8. /var/www/web29277955/html/!!!XYZ!!!/lib/system/event/EventHandler.class.php (177): wcf\system\event\EventHandler->executeInheritedActions(…)
    9. /var/www/web29277955/html/!!!XYZ!!!/lib/page/AbstractPage.class.php (141): wcf\system\event\EventHandler->fireAction(…)
    10. /var/www/web29277955/html/!!!XYZ!!!/lib/page/CmsPage.class.php (115): wcf\page\AbstractPage->assignVariables(…)
    11. /var/www/web29277955/html/!!!XYZ!!!/lib/page/AbstractPage.class.php (294): wcf\page\CmsPage->assignVariables(…)
    12. /var/www/web29277955/html/!!!XYZ!!!/lib/page/AbstractPage.class.php (114): wcf\page\AbstractPage->show(…)
    13. /var/www/web29277955/html/!!!XYZ!!!/lib/system/request/Request.class.php (83): wcf\page\AbstractPage->__run(…)
    14. /var/www/web29277955/html/!!!XYZ!!!/lib/system/request/RequestHandler.class.php (96): wcf\system\request\Request->execute(…)
    15. /var/www/web29277955/html/!!!XYZ!!!/index.php (9): wcf\system\request\RequestHandler->handle(…)

    Alfahosting sagt: können wir nichts machen. Es betrifft hier wohl die Tabelle table_definition_cache, die auf einen Standardwert von 400 eingestellt ist und von denen nicht verändert werden "kann".

    So schmiert das kleine Forum immer wieder ab, weil die Last auf dem Server wohl schlicht zu hoch ist. Das betrifft allerdings auch noch 2 andere Foren von mir, die auf zwei anderen Tarif bei Alfahosting liegen. Scheint wohl also ein globales Problem zu sein. Ich liege mit dem einen Forum auf dem Server 109.237.138.11 und wenn ich hier schaue, welche Anzahl Domains dort gehostet werden...da kann einem nur noch übel werden.

    Welche Möglichkeiten bleiben mir denn noch? Aufgetreten sind die Meldungen schleichend, gefühlt seit gut einem halben Jahr regelmäßig. Ob die Software zu verschwenderisch mit Ressourcen umgeht, kann ich nicht sagen. Ich bin kein Programmierer, sondern Kunde von Woltlab und nutze dessen Produkt.

    Kann wer Tipps geben, der bereits EBENSO MIT DEM 1615 zu tun hatte?

    Danke schön!

    Einmal editiert, zuletzt von pimpi (3. Februar 2020 um 12:03)

    • Offizieller Beitrag

    Hallo,

    Alfahosting sagt: können wir nichts machen. Es betrifft hier wohl die Tabelle table_definition_cache, die auf einen Standardwert von 400 eingestellt ist und von denen nicht verändert werden "kann".

    Das „kann“ durch den Webhoster durchaus verändert werden. Der Webhoster „möchte“ augenscheinlich aber keine Änderung vornehmen - aus welchem Grund auch immer. Durch einen derartig geringen Wert wird die Leistung des Datenbankservers ganz unabhängig von dem Auftreten der Fehlermeldung künstlich beschränkt, weil dieser ständig die Tabellendefinitionen von der Festplatte nachladen muss, wenn die Definitionen durch Aktivitäten anderer Kunden verworfen werden, weil das Limit erreicht ist.

    Welche Möglichkeiten bleiben mir denn noch?

    Nur ein Wechsel des Webhosters.

    Kann wer Tipps geben, der bereits EBENSO MIT DEM 1615 zu tun hatte?

    Ich verweise auf diesen Beitrag: RE: FROM wcf1_session WHERE spiderID = ? AND userID IS NULL'

  • Nur ein Wechsel des Webhosters.

    Tja nun, das wäre schon ein Akt und bei jährlicher Zahlungsweise auf irgendwie ätzend. Welchen Hoster würde denn Woltlab empfehlen? Wenn ich bei der nächsten Gurke lande, wo "Business" eher für "Masse" steht...bringt das keine Punkte.

  • Bei allinkl war ich ebenso über Jahre. Das UI bei denen war ne Katastrophe und funktional auf dem Stand aus dem Jahr 2000. Hat sich hier etwas getan? Das ist bei Alfahosting ein großer Vorteil, die Verwaltung funktioniert 1a. Wenn es die Server ebenso würden...Träumchen. Webgo sagt mir nichts, ich frage gleich mal nach der Variable.

    • Offizieller Beitrag

    Hallo,

    Tja nun, das wäre schon ein Akt und bei jährlicher Zahlungsweise auf irgendwie ätzend.

    Grundsätzlich könntest du natürlich auch versuchen deinen aktuellen Webhoster zu überzeugen, dass der aktuelle Wert von 400 unter jedem Betrachtungsmaßstab unsinnig ist.

    Welchen Hoster würde denn Woltlab empfehlen?

    An dieser Stelle kann ich nur auf den Webhoster Sammelthread verweisen.

  • Grundsätzlich könntest du natürlich auch versuchen deinen aktuellen Webhoster zu überzeugen, dass der aktuelle Wert von 400 unter jedem Betrachtungsmaßstab unsinnig ist.

    Schon mehrfach angesprochen, keine Chance. Die wollen, dürfen, können nicht. Sonst geht der Server mit den ganzen Kunden wohl gleich in die Knie. Verkaufen wollen Sie mir den Server für das Mini Forum. Absolut übertrieben! Ich warte die Antwort vom Support ab, aber wie die ausfallen wird kann ich mir denken. Bleibt wohl doch nur der Wechsel.

  • Antwort von webgo: global haben die dort 1400 eingestellt. Sollte das reichen? Einstellbar ist der Wert nicht. Aber 1400 ist zumindest deutlich besser als 400 ^^

    • Offizieller Beitrag

    Hallo,

    Antwort von webgo: global haben die dort 1400 eingestellt. Sollte das reichen? Einstellbar ist der Wert nicht. Aber 1400 ist zumindest deutlich besser als 400 ^^

    Jede Tabellenstruktur, die im Arbeitsspeicher des Servers vorgehalten werden soll benötigt einen „Slot“ im table_definition_cache. WoltLab Suite besteht in der Standardinstallation aus über 170 Tabellen, mit Plugins sind es mehr. Einige Tabellen werden eher selten benötigt, über den Daumen gepeilt sind es aber sicherlich 20 Tabellen mit denen dauerhaft interagiert wird. Bei nur 70 Kunden mit WoltLab Suite auf dem Datenbankserver wären also die 1400 Slots belegt. Jede weitere benötigte Tabelle führt dazu, dass eine der „häufig gebrauchten“ Tabellen aus dem Arbeitsspeicher entfernt werden und beim nächsten Mal wieder geladen werden muss. Das nachladen entfernt dann wiederum eine andere Tabelle aus dem Arbeitsspeicher.

    Selbst auf meinem privaten MySQL-Server habe ich den Wert auf 1500 konfiguriert. 887 Slots sind tatsächlich belegt. Auf dem WoltLab-Demoserver ist die Konfiguration im 5-stelligen Bereich (dort sind alle Slots belegt).

    Fazit: 1400 ist zwar mehr als doppelt so hoch wie der minimal mögliche (!) Wert von 400, aber trotzdem lächerlich klein.

  • Katastrophe. Gibt's denn keinen Anbieter der sich empfehlen lässt, ohne dass einen das Hobby Forum arm macht? Wenn ich jetzt 50 Hoster anschreibe und nach dem Wert frage, sind wohl die 1400 von webgo schon fast Rekord.

  • Hab Antwort bekommen:

    Zitat

    Hallo Herr X,

    ich bedanke mich für Ihre Rückmeldung und die offenen und ehrlichen Worte.

    Zusammen mit einem unserer Systemadministratoren habe ich mir die Problematik noch einmal angesehen. Ihr beschriebener Fehlereffekt taucht in unserer gesamten Ticket-Historie nur vereinzelt und sehr geringer Anzahl auf. Auffällig ist, dass hier nahezu ausschließlich Woltlab-Nutzer betroffen sind. Es handelt sich somit um ein eher seltenes Problem.

    Da unsere aktuelle Confixx-Webhosting-Plattform das End-of-Lifetime erreicht hat und keine individuellen Anpassungen mehr durchgeführt werden dürfen, habe ich mich zu unserer in den Startlöchern stehenden Webhosting 2.0 Plattform ein wenig schlau gemacht. Diese soll Ende des 1.Quartals bzw. Anfang des 2 Quartals für Neubestellungen freigeben werden. Dort liegt der Wert für table_definition_cache laut unserer Dokumentation bei 2048. Nachfolgend planen wir eine großangelegte Migration aller Bestandskunden auf diese Plattform. Dies wird sich aufgrund der Endkunden-Serveranzahl jedoch bis in das Jahr 2021 hineinziehen, befürchte ich.

    Mein Vorschlag bzw. meine Alternative zu einem Cloud-Server oder Anbieterwechsel wäre demnach ein neuer Webhosting-Tarif auf Basis unserer neuen Plattform. Diesen könnten wir dann auch mit den vorausbezahlten Entgelt verrechnen.

    Woltlab ist damit Schuld ;) Bei uns auf Arbeit hosten wir ja zahlreiche Shopsysteme (wir bieten eine eigene Shopsoftware an). Und hier liegt der Wert von table_definition_cache je nach Server zwischen 15.000 und 65.000. Das nützt mir für meine privaten Projekte nur leider nix. 2048 ist also deutlich besser als 400, ob es das Abschmieren der Foren verhindert...ich weiß es nicht.

    • Offizieller Beitrag

    Hallo,

    Woltlab ist damit Schuld

    im Sinne der besseren Sicherheit setzt WoltLab Suite auf echte Prepared Statements bei denen die Platzhalter durch den Datenbankserver eingesetzt werden. Der Standardwert bei PHP ist die Simulation von Prepared Statements. Hierbei werden die Platzhalter durch PHP eingesetzt und anschließend als „unprepared“-Statement an den Datenbankserver gesetzt. Bei letzteren kann die Fehlermeldung technisch nicht auftreten, da die vollständige Durchführung der Abfrage innerhalb von einem einzigen Schritt abläuft in dem die Tabelle nicht aus dem Arbeitsspeicher geworfen wird.

    Ich denke nicht, dass die Verwendung von elementaren Funktionen von MySQL als „Schuld haben“ betrachtet werden kann, nur weil andere Anwendungen diese Funktionalität typischerweise nicht verwendet, wodurch die Funktionalität dem Webhoster nicht bekannt ist.

    Warum der Webhoster der Meinung ist, dass 2048 ein angemessener Wert für den table_definition_cache ist, ist mir unklar. Das mag funktionieren, wenn eine einzige Applikation eines einzigen Kunden auf dem Datenbankserver läuft, aber bei einem geteilten System ist das wie Fahren mit angezogener Handbremse ?(.

  • Ja das mit der Handbremse trifft es ganz gut. Ich kauf mir auch keinen Porsche Turbo und drossel den auf 10 PS. Da kann die Hardware noch so üppig sein. Tjo was mach ich da nun. Wenn ich intern trotzdem alles von Hand umziehen muss, kann ich auch zu einem anderen Anbieter. Nur finden ist das Problem. Es mag ja zahlreiche gute Hoster geben, nur hosten die wohl fast alle nur WordPress Blogs und wenn hier dann wieder gefühlt ich der einzige Mensch im Universum bin, wo ein Forum eingesetzt wird...pfffff :D

  • Bei allinkl war ich ebenso über Jahre. Das UI bei denen war ne Katastrophe und funktional auf dem Stand aus dem Jahr 2000. Hat sich hier etwas getan?

    Ich habe 2018 von einem US Provider (dort hatte ich PLESK) wegen der DSGVO zu Allinkl gewechselt und war vom Retro-UI KAS auch nicht begeistert. Aber letztlich habe ich alles, was ich brauche. Was fehlt dir denn an Funktionen?

    table_definition_cache ist auf 4000 eingestellt (Webhosting Premium, 108,36 EUR jährlich inkl. 20% MwSt (Österreich), 50 Kunden pro Server.

    lg,

    Chris

  • Hab früher auch zahlreiche Projekte auf mehrere Hoster verteilt und da war allinkl mit der UI anstrengend. Die Webseite sieht sogar aus wie früher. Wenn die UI immer noch so ist, finde ich das mit Stand 2020 einfach schwach. Aber gut, vielleicht stecken Sie die Kohle ja in die Server. Wenn es läuft, ist ja alles gut :D Im größten Tarif bei denen (https://all-inkl.com/webhosting/business/) sind es 30 Kunden je Server. Klingt wenig, aber wenn dann alle 30 Kunden ihre 20 Domains projektieren, sind das auch 600 Kunden. Wie tun? Ich muss wohl alle bekannten Anbieter anschreiben, die zumindest durch ihre Größe etwas Sicherheit bieten...und nachfragen.

    • Offizieller Beitrag

    Hallo,

    Wenn die UI immer noch so ist, finde ich das mit Stand 2020 einfach schwach.

    ich kann mir an der Stelle nicht verkneifen zu bemerken, dass dein aktueller Webhoster laut seiner Antwort noch immer Confixx zu verwenden scheint. Diese Software wird seit 9 Jahren nicht mehr weiterentwickelt.

    Klingt wenig, aber wenn dann alle 30 Kunden ihre 20 Domains projektieren, sind das auch 600 Kunden.

    Ich bezweifele, dass jeder dieser Kunden 20 Domains aufschalten wird und dann auch noch auf jeder der Domains eine separate Software mit vielen Datenbanktabellen betreibt. In der Regel werden das wohl Aliasdomains sein. Ein Wert von 4000 auf die von -chris- genannten 50 Kunden wären 80 Tabellen pro Kunde. Wenn man dabei dann berücksichtigt, dass die Zielsetzung nur ist, dass die Tabelle länger als ein paar Millisekunden im table_definition_cache verbleibt (eben bis die aktuelle Datenbankabfrage durchgeführt ist), dann ist das ein Wert mit dem zumindest die beklagte Fehlermeldung vermieden werden sollte.

  • Über confixx brauchen wir nicht diskutieren, das ist einfach Retro. Ich meinte die Benutzeroberfläche für Kunden, also der Alfahosting Admin. Der ist ziemlich gut und informativ. Auch reagiert der Support immer schnell. Es kommt auf die Antwort von denen an. Muss ich von Hand alle Projekte umziehen, kann ich statt dem neuen webhosting Modell auch direkt den Anbieter wechseln. Mein Vorschlag an Alfahosting wäre ein eigener Tarif, der eher den Forenbetrieb im Fokus hat. Mal schauen wie die Antwort ausfällt.

    Wechsel ich doch, bleibt die Frage: pokern und für jedes Forum ein kleinerer Tarif, oder alle im größten Tarif bündeln. Steigt hier die DB aus, sind alle 5 Foren down. Momentan sind die bei Alfahosting auf 3 Tarife verteilt. Wo allerdings auch jeder je nach Tagesform aussteigt. Drama ^^

  • Im größten Tarif bei denen (https://all-inkl.com/webhosting/business/) sind es 30 Kunden je Server. Klingt wenig, aber wenn dann alle 30 Kunden ihre 20 Domains projektieren, sind das auch 600 Kunden. Wie tun? Ich muss wohl alle bekannten Anbieter anschreiben, die zumindest durch ihre Größe etwas Sicherheit bieten...und nachfragen.

    Wenn du so rechnest, wäre es viel schlimmer als du glaubst;). Die 20 Domains sind so gemeint, dass du 20 Domains über Allinkl kostenlos registrieren kannst, wobei Allinkl die jährlichen Gebühren für die Domains übernimmt. Darüber hinaus ist die Anzahl der Domains, die du auf deinem Account hosten kannst, unbegrenzt, sogar bei meinem Premium Account.

    Die ersten 3 Monate sind bei Allinkl gratis, also genug Zeit zum Ausprobieren. Du kannst monatlich bezahlen und kündigen, wenn du ein Konto in Deutschland hast (außerhalb Dt.land geht es nach den 3 Gratis-Monaten nur jährlich).

    lg,

    Chris

  • Bei den halbwegs glaubhaften Magazinen wie connect, hat allinkl auch im Vergleich mit am besten abgeschnitten. Falls ich wechseln muss, dann sind die mit im Pool. Hetzner habe ich angefragt, mal schauen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!