Could not execute statement 'DELETE FROM wcf1_acp_session

  • Betroffene Version
    WoltLab Suite 5.3

    Hallo Zusammen,

    seit einem Umzug zum neuen Webhoster wird ständig folgender Fehler geloggt:

    Zitat

    Thu, 18 Mar 2021 13:32:17 +0000Message: Could not execute statement 'DELETE FROM wcf1_acp_session WHERE lastActivityTime < ?'File: /lib/system/database/statement/PreparedStatement.class.php (105)

    Die Tabelle wcf1_acp_session ist dabei völlig leer. Könnt ihr mir weiterhelfen?

    Danke und Gruß

    avalanche

  • Sorry, ich hatte nur die kurze Fehlermeldung kopiert. Hier die vollständige Fehlermeldung:

    Aufgerufene URL
    POST /forum/index.php?ajax-proxy/&t=dfa1f0005db87ea85bd5af6bf3693f7300ed0e9b
    Referrer
    https://www.loksimulatoren.de/forum/
    WoltLab Suite
    5.3.5
    PHP
    7.3.27-9+0~20210227.82+debian10~1.gbpa4a3d6
    Fehlermeldung
    Could not execute statement 'DELETE FROM wcf1_acp_session WHERE lastActivityTime < ?'
    Art
    wcf\system\database\exception\DatabaseQueryExecutionException
    Datei (Zeile)
    /home/www/loksimulatoren/lib/system/database/statement/PreparedStatement.class.php (105)
    Query Parameter 1
    1616072537
    Stacktrace
    1. /home/www/loksimulatoren/lib/data/acp/session/ACPSessionEditor.class.php (74): wcf\system\database\statement\PreparedStatement->execute(…)
    2. /home/www/loksimulatoren/lib/system/cronjob/SessionCleanUpCronjob.class.php (26): wcf\data\acp\session\ACPSessionEditor::deleteExpiredSessions(…)
    3. /home/www/loksimulatoren/lib/system/cronjob/CronjobScheduler.class.php (271): wcf\system\cronjob\SessionCleanUpCronjob->execute(…)
    4. /home/www/loksimulatoren/lib/system/cronjob/CronjobScheduler.class.php (71): wcf\system\cronjob\CronjobScheduler->executeCronjob(…)
    5. /home/www/loksimulatoren/lib/data/cronjob/CronjobAction.class.php (232): wcf\system\cronjob\CronjobScheduler->executeCronjobs(…)
    6. /home/www/loksimulatoren/lib/data/AbstractDatabaseObjectAction.class.php (204): wcf\data\cronjob\CronjobAction->executeCronjobs(…)
    7. /home/www/loksimulatoren/lib/action/AJAXProxyAction.class.php (75): wcf\data\AbstractDatabaseObjectAction->executeAction(…)
    8. /home/www/loksimulatoren/lib/action/AJAXInvokeAction.class.php (94): wcf\action\AJAXProxyAction->invoke(…)
    9. /home/www/loksimulatoren/lib/action/AbstractAction.class.php (47): wcf\action\AJAXInvokeAction->execute(…)
    10. /home/www/loksimulatoren/lib/action/AJAXInvokeAction.class.php (61): wcf\action\AbstractAction->__run(…)
    11. /home/www/loksimulatoren/lib/system/request/Request.class.php (83): wcf\action\AJAXInvokeAction->__run(…)
    12. /home/www/loksimulatoren/lib/system/request/RequestHandler.class.php (107): wcf\system\request\Request->execute(…)
    13. /home/www/loksimulatoren/forum/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)
    /home/www/loksimulatoren/lib/system/database/statement/PreparedStatement.class.php (93)
    Stacktrace
    1. /home/www/loksimulatoren/lib/system/database/statement/PreparedStatement.class.php (93): PDOStatement->execute(…)
    2. /home/www/loksimulatoren/lib/data/acp/session/ACPSessionEditor.class.php (74): wcf\system\database\statement\PreparedStatement->execute(…)
    3. /home/www/loksimulatoren/lib/system/cronjob/SessionCleanUpCronjob.class.php (26): wcf\data\acp\session\ACPSessionEditor::deleteExpiredSessions(…)
    4. /home/www/loksimulatoren/lib/system/cronjob/CronjobScheduler.class.php (271): wcf\system\cronjob\SessionCleanUpCronjob->execute(…)
    5. /home/www/loksimulatoren/lib/system/cronjob/CronjobScheduler.class.php (71): wcf\system\cronjob\CronjobScheduler->executeCronjob(…)
    6. /home/www/loksimulatoren/lib/data/cronjob/CronjobAction.class.php (232): wcf\system\cronjob\CronjobScheduler->executeCronjobs(…)
    7. /home/www/loksimulatoren/lib/data/AbstractDatabaseObjectAction.class.php (204): wcf\data\cronjob\CronjobAction->executeCronjobs(…)
    8. /home/www/loksimulatoren/lib/action/AJAXProxyAction.class.php (75): wcf\data\AbstractDatabaseObjectAction->executeAction(…)
    9. /home/www/loksimulatoren/lib/action/AJAXInvokeAction.class.php (94): wcf\action\AJAXProxyAction->invoke(…)
    10. /home/www/loksimulatoren/lib/action/AbstractAction.class.php (47): wcf\action\AJAXInvokeAction->execute(…)
    11. /home/www/loksimulatoren/lib/action/AJAXInvokeAction.class.php (61): wcf\action\AbstractAction->__run(…)
    12. /home/www/loksimulatoren/lib/system/request/Request.class.php (83): wcf\action\AJAXInvokeAction->__run(…)
    13. /home/www/loksimulatoren/lib/system/request/RequestHandler.class.php (107): wcf\system\request\Request->execute(…)
    14. /home/www/loksimulatoren/forum/index.php (9): wcf\system\request\RequestHandler->handle(…)
  • Den Hoster kenne ich nur dem Namen nach, dazu kann ich leider nichts sagen. Aber die grundsätzliche Server-Konfiguration sollte schon auch in den kleineren Paketen im vertretbaren Bereich liegen und wenigstens den allgemeinen Mindestanforderungen genügen.

    Gruß

    Jörg

    (Jaydee)

  • Auch hier klingt es nach einem (beim neuen Hoster) zu klein definierten Table-Cache.

    Ich habe das gerade nochmal nachgeprüft. Der table_definition_cache liegt beim neuen Webhoster webgo bei 2000, beim alten Webhoster bei 1400. Aktuell sind 10 Domains auf dem gleichen Server (allesamt eher statische Websites, nur 1 kleines Shop-System), vorher waren es über 100. Wenn ich den anderen Thread so verfolge, sollte meine Installation also voll und ganz im Rahmen liegen? :/

  • So ist es, wobei die Konstellation auf Deinem neuen Server zunächst mal deutlich besser klingt als bisher. Ein Wert von 2000 klingt vordergründig auch auch erst mal realistisch und ausreichend, ist aber wie gesagt auch von weiteren Parametern abhängig. Möglicherweise hat es aber in Deinem Fall tatsächlich eine andere Ursache.

    Gruß

    Jörg

    (Jaydee)

  • Aktuell sind 10 Domains auf dem gleichen Server (allesamt eher statische Websites, nur 1 kleines Shop-System), vorher waren es über 100. Wenn ich den anderen Thread so verfolge, sollte meine Installation also voll und ganz im Rahmen liegen? :/

    Der Tarif „SSD-Platin“ liegt leistungsmäßig zwischen „Profi“ und „Business“. Du teilst dir den CPU-Kern wie im Tarif „Profi“ mit 16 Kunden, aber hast mit 1024 MB RAM soviel RAM wie im Tarif „Business“. Und nebenbei viel Speicherplatz. Wenn man den braucht ganz nett. Frag doch einfach mal beim Support nach, ob die bspw. zur fraglichen Zeit irgendwelche Probleme hatten, oder andere Kunden den Server massiv auslasteten, so dass es zu diesen Fehlern kommt.

    Ergänzung: Hab gerade mal bei uns nachgeschaut. Über phpMyAdmin wird zumindest für MariaDB ein Wert von 400 angezeigt (Tarif „Business“).

  • Zumindest der Hoster (Server-Betreiber) kann es auf jeden Fall. Welcher Wert dort sinnvoll ist, hängt von diversen Umständen ab, da kann man pauschal keine bestimmte Zahl nennen.

    Was man aber mit Bestimmtheit sagen kann, ist. dass "400" in aller Regel zu wenig und nicht unbedingt zielführend ist. Aus meiner Sicht gibt es für eine derartige Restriktion eigentlich auch keine (technische) Begründung.

    Gruß

    Jörg

    (Jaydee)

  • Ich weiß nicht, ob das bei Deinem Hoster auf dem Wege möglich ist, aber da Du ja Zugriff auf phpMyAdmin hast, könntest Du mal Folgendes probieren:

    In der "Startebene", also dort wo Du die einzelnen Datenbanken siehst, gehst Du auf "Variablen". Vermutlich warst Du da auch schon, wenn Du den Wert kennst.

    Dort suchst Du nochmals (sollte recht weit unten stehen, in alphabetischer Reihenfolge) den Eintrag table_definition_cache, das schreibe ich jetzt bewusst für evtl. nachfolgende Leser mit demselben Problem. In dieser Zeile ist nun der aktuelle Wert zu sehen. Sollte da die genannte "400" stehen, testweise mal mit "2000" überschreiben und dann beobachten. Temporär wird der Wert zunächst übernommen, für eine dauerhafte Erhöhung ist aber ein entsprechender Eintrag in die my.cnf sowie anschließender Neustart des MySQL-Servers erforderlich (was der Hoster nicht tun wird).

    Zum Testen sollte dieser Vorgang aber mal reichen.

    Gruß

    Jörg

    (Jaydee)

  • Ja, auf normalen Shared-Servern eher unwahrscheinlich. Auch wenn es bei einigen wohl möglich ist. Wenn dieser Wert an der Stelle nicht nur sichtbar, sondern auch editierbar ist, sollte sich die Änderung auch temporär auswirken. Bei fehlenden Berechtigungen wäre das Feld zwar (schwach) sichtbar, aber nicht änderbar. Also so, wie es auch bei anderen Parametern der Fall ist.

    Gruß

    Jörg

    (Jaydee)

  • Doch, wenn es in Form eines "Eingabefeldes" dargestellt wird, schon. Wenn man es NICHT kann, kommt man dort an der Stelle mit dem Cursor gar nicht erst rein. Ansonsten lässt sich dieser Wert problemlos überschreiben.

    Wie gesagt, natürlich nur mit den entsprechenden Datenbank-User Rechten. Ansonsten nicht.

    Deshalb oben meine Einleitung ""ich weiß nicht, ob es bei Dir möglich ist...".

    Gruß

    Jörg

    (Jaydee)

Jetzt mitmachen!

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