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

  • Antwort von allinkl:

    Zitat

    Hallo Herr X,

    der Arbeitsspeicher (Memory_Limit), der im Business Tarif zum Ausführen von PHP Scripten zur Verfügung steht, ist 512 MB groß und der table definition cache in der Datenbank beträgt 496 Bytes.

    Also 1 Byte in Bit, macht *8 knapp 4000, oder hab ich nen Denkfehler?

    • Offizieller Beitrag

    Hallo,

    Das ist nur eine Zahl, demnach sind für All-Inkl auch nur 496 Tabellen(Definitionen) im Cache.

    Die Zahl sieht verdächtig nach einem Vertipper für 4096 aus. Bytes sind natürlich unabhängig davon unsinnig.

    pimpi Ich empfehle eine Nachfrage. Folgende Abfrage liefert das was du hören möchtest, gerne kannst du die an den Support so weitergeben.

    Code
    mysql> SHOW VARIABLES LIKE 'table_definition_cache';
    +------------------------+-------+
    | Variable_name          | Value |
    +------------------------+-------+
    | table_definition_cache | 2000  |
    +------------------------+-------+
    1 row in set (0.00 sec)
  • Ich hab das mal bei Allinkl. im Business Paket getestet

    Code
    +------------------------+-------+
    | Variable_name          | Value |
    +------------------------+-------+
    | table_definition_cache | 4000  |
    +------------------------+-------+

    Das gleiche bei Allinkl Premium

    lg,

    Chris

  • Eben diese Antwort kam auch gerade von einem anderen allinkl Mitarbeiter. Also 4000 ist definitiv besser als 400 und auch besser als die etwas über 2000 nach der Umstellung bei alfahosting. Tjo, dann geht es wohl zurück zu allinkl.

  • Antwort von Hetzner: die passen den Wert an. Wie genau und in welchem Bereich, habe ich gerade erfragt. Bleibt dann die Wahl: allinkl oder hetzner. Bei beiden war ich schon. Hetzner war zumindest geschmeidiger zu bedienen. Performance? Gute Frage, ob die sich hier etwas nehmen...?

    Antwort Hetzner:

    Zitat

    Der table_definition_cache wird in der Praxis so gesetzt dass der Wert hoch genug ist, um die Struktur aller aktiven Datenbanken im Cache zu halten.

    Der gesetzte Wert kann hier jedoch nicht explizit zugesichert werden, der niedrigste Wert welchen ich bei Prüfung einiger SQL Server feststellen konnte liegt jedoch schon bei 20.000, teilweise auch bis 45.400, eben je nach Bedarf um die Performance zu optimieren.

    Das klingt doch mal anständig!

    Einmal editiert, zuletzt von pimpi (4. Februar 2020 um 11:56)

  • Ich bin mit meinem 5 Foren nun schon einige Monate bei Hetzner, läuft deutlich geschmeidiger und schneller. Die Auszeiten wie bei Alfahosting sind weg (kurze Wartungsarbeiten am Server hat eh jeder Anbieter) und der 1615 kam gar nicht mehr.

  • 4 Domains laufen derzeit auf dem Server

    Wenn du dort alles 4 mal das WSC laufen hast oder andere CMS Systeme die nicht all zu kleine Datenbanken haben, dann sollte dieser wert auf jedenfalls erhöht werden. Ansonsten wirst du immer und immer wieder diesen Fehler bekommen.

    p.s.

    Dieser Wert ist der kleinste Wert der dort eingetragen werden kann, ggfs. sollte dein Hoster/Admin mal die komplett DB Konfiguration an deinen Verbrauch anpassen :)

  • Hab mal auf die Überwachung geguckt

    Mögliche Performance-Probleme

    ProblemEmpfehlung
    Suboptimale Zwischenspeicher-Methode.Sie verwenden den MySQL-Anfragen-Cache mit einer relativ hohen Traffic-Datenbank. Es wäre überlegenswert, Memcached statt MySQL Query Cache verwenden vor allem, wenn Sie mehrere Slaves einsetzen.
    Zu viele Sortierungen verursachen temporäre Tabellen.Ziehen Sie in Betracht, sort_buffer_size und/oder record_rnd_buffer zu erhöhen, je nach verfügbarem Speicher Ihres Systems.
    Es werden viele Zeilen sortiert.Auch wenn ein hoher Anteil an Zeilensortierungen nicht falsch ist, sollten Sie darauf achten, dass die Abfragen, die viele Sortierungen verwenden, indizierte Spalten in der ORDER-BY-Klausel verwenden, da dies zu viel schnellerem Sortieren führt.
    Es werden zu viele Joins ohne die Benutzung von Indizes durchgeführt.Dies bedeutet, dass Joins vollständige Tabellenscans durchführen. Indizes für die Spalten zu verwenden, die in den Join-Bedingungen eingesetzt werden, wird die Joins erheblich beschleunigen.
    Die Lese-Rate des ersten Indexeintrag ist hoch.Dies bedeutet in der Regel häufig vollständige Indexscans. Vollständige Indexscans sind schneller als Tablenscans aber sie kosten viele CPU-Zyklen in großen Tabellen, wenn diese Tabellen große Mengen von Aktualisierungen und Löschungen haben oder hatten. Ein Ausführen von "OPTIMIZE TABLE" auf diese Tabellen kann die Menge verringern und/oder die Geschwindigkeit der vollständigen Indexscans beschleunigen. Abgesehen davon können vollständige Indexscans nur durch Umschreiben der Abfragen reduziert werden.
    Die Lese-Rate fester Positionen ist hoch.Dies deutet darauf hin, dass viele Abfragen Sortieren und/oder vollständige Tabellen-Scan benötigen, einschließlich Join-Abfragen die keine Indizes verwenden. Fügen Sie Indizes hinzu wo zutreffend.
    Lese-Rate nächste Tabellenzeile ist hoch.Dies deutet darauf hin, dass viele Abfragen Full Table Scans durchführen. Fügen Sie Indizes hinzu wo zutreffend.
    Viele temporäre Tabellen werden auf die Festplatte geschrieben, anstelle im Speicher gehalten zu werden.Erhöhen von max_heap_table_size und tmp_table_size könnten helfen. Jedoch werden einige temporären Tabellen immer unabhängig vom Wert dieser Variablen auf den Datenträger geschrieben. Um diese zu verhindern müssen Sie Ihre Abfragen so umschreiben das es nicht zu diesen Bedingungen kommt (Innerhalb einer temporären Tabelle: Vorhandensein eines BLOB- oder TEXT-Spalte oder eine Spalte größer als 512 Bytes) wie am Anfang von Artikel der Pythian Group erwähnt wird
    MyISAM Schlüssel-Cache (Indize Cache) % benutz ist niedrig.Sie müssen möglicherweise Ihren key_buffer_size verkleinern, überprüfen Sie Ihre Tabellen um zu sehen ob Indizes entfernt wurden oder Überprüfen Sie Abfragen und Erwartungen um zu sehen welche Indizes verwendet werden.
    Hohe Anzahl an Tabellen-Öffnungen.Öffnen von Tabellen erfordert Festplatten I/O, welches langsam ist. Erhöhung von Table_open_cache könnte dies vermeiden.
    Zu viele Verbindungen werden abgebrochen.Verbindungen sind in der Regel abgebrochen, wenn sie nicht autorisiert werden können. Dieser Artikel könnte Ihnen helfen der Quelle auf die Spur zu kommen.
    Zu viele Clienten werden abgebrochen.Clienten werden in der Regel abgebrochen, wenn sie ihre Verbindung zu MySQL nicht richtig schließen. Dies kann aufgrund von Netzwerkproblemen oder Quellcode der Datenbank-Handler nicht ordnungsgemäß schließen passieren. Überprüfen Sie Ihre Netzwerk und Quellcode.
    Die InnoDB Protokollgröße ist nicht ausreichend groß.Es üblicherweise ausreichend innodb_log_file_size auf 25% der Größe von Innodb_buffer_pool_size einzustellen. Eine sehr große innodb_log_file_size verlangsamt die Wiederherstellungszeit nach einem Datenbank Absturz erheblich. Siehe auch diesen Blog-Eintrag
    Der Abfragen-Zwischenspeicher ist nicht aktiviert.Der Abfrage-Zwischenspeicher verbessert die Leistung, wenn er korrekt konfiguriert wurde. Aktivieren Sie ihn indem Sie query_cache_size auf ein zweistelligen MiB-Wert und query_cache_type auf 'ON' setzen. Beachten Sie: Ignorieren Sie diese Empfehlung, wenn Sie memcached benutzen.
  • Wenn das dein eigener Server ist und du nur eine-zwei Webseite hast, sollte das ausreichen.

    Hast du aber mehrere dann müsste dieser wert höher gestellt werden, je nachdem was deine installierten Plugins alles hinzugefügt haben ;)

    Was haben den unsere Webseiten bei dir fürn Wert, aus reiner Neugier gefragt :)

  • Ich bin mit meinem 5 Foren nun schon einige Monate bei Hetzner, läuft deutlich geschmeidiger und schneller. Die Auszeiten wie bei Alfahosting sind weg (kurze Wartungsarbeiten am Server hat eh jeder Anbieter) und der 1615 kam gar nicht mehr.

    Und welches Paket bei Hetzner?

  • Moin :)

    Ich möchte dieses Thema noch einmal aufgreifen, da ich eine Lösung abseits der WoltLab Cloud gefunden habe. Ja, man glaubt es kaum, das dies möglich ist. Für Nutzer, die gerne alles selbst in die Hand nehmen, keinen Server nutzen möchten (wäre aber auch möglich) oder denen das nötige Kleingeld fehlt, empfehle ich gerne Febas. Diesen Anbieter findet man kaum in den einschlägigen Testberichten, weil selbige eh fast alle nur gestellt sind. Wenn man aber Berichte findet, dann sind diese alle positiv.

    Ich war skeptisch, das gebe ich ehrlich zu. Da ich aber keine Lust auf neue Abenteuer hatte, der Support mir dort zu jeder Zeit meine Fragen ausführlich und verständlich beantwortet hat, so wie man es auch von WoltLab kennt, wenn man ordentliche Fragen stellt und weil der Wert von table_definition_cache bei über 20000 (zwanzigtausend) liegt (habe die genau Zahl jetzt nicht im Kopf) habe ich vor einigen Monaten den Wechsel vollzogen. Seid dem ist Funkstille bei den Fehlermeldungen. Alles läuft bestens. Und wenn etwas nicht funktionieren sollte, reicht ein kurzes Ticket und das Problem wird gelöst.

    Was mir ebenfalls sehr gefällt, die Domainpreise. Für eine DE Domain zahlt man dauerhaft, pro Jahr 2,63 €. Und so geht es immer weiter. Der Provider hat sich wirklich Mühe gegeben, was die Verwaltung angeht, etc. Ich kann mich wirklich nicht beklagen. Hier stimmt das Preis - Leistungsverhältnis defninitiv.

    In diesem Sinne, einen schöne Weihnachtszeit und einen guten Start ins neue Jahr.

    Liebe Grüße

    webpexel

Jetzt mitmachen!

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