"Suchindex auf InnoDB umstellen" zu anspruchsvoll für Webspace

  • Betroffene Version
    WoltLab Suite 5.4
    Betroffene App
    WoltLab Suite Core

    Die Ausführung von "Suchindex auf InnoDB umstellen" unter "Anzeigen aktualisieren" schlägt in meiner Test-Installation vom WoltLab Suite 5.4 auf dem Webspace von all-inkl (Premium) immer fehl. Nach langem Warten erscheint jedes Mal die Fehlermeldung:

    Zitat

    Gateway Timeout

    The gateway did not receive a timely response from the upstream server or application.

    Ich weiß leider nicht, ob das ein Prozess ist, der in irgendeiner Weise optimiert werden kann, dass er weniger anspruchsvoll für den Server ist. Darum melde ich das hier als Problem. Falls softwareseitig keine Optimierung möglich ist, bin ich auch für einen Tipp dankbar, was ich probieren könnte. ;)

    • Offizieller Beitrag

    Hallo,

    der Worker stellt pro Durchlauf nur eine Tabelle um, in dem MySQL angewiesen wird, die Engine zu ändern. Das lässt sich nicht weiter optimieren, sondern skaliert direkt mit (a) der Menge an enthaltenen Daten und (b) der Performance des Datenbank-Servers.

    Falls softwareseitig keine Optimierung möglich ist, bin ich auch für einen Tipp dankbar, was ich probieren könnte. ;)

    Ich gehe mal stark davon aus, dass das Problem der Suchindex für Beiträge ist, da dies tendenziell die Tabelle mit den meisten Inhalten ist. Du kannst versuchen, den Query per MySQL auf der CLI (via SSH!) auszuführen, damit du nicht von den Laufzeitbeschränkungen des Webservers beeinträchtigt wirst:

    SQL
    ALTER TABLE wbb1_post_search_index ENGINE = InnoDB;

    Gerade per CLI sollte es eigentlich durchgehen, weil dir dann ein lahmer Datenbank-Server ziemlich egal ist.

  • Alexander Ebert 1. Juli 2021 um 22:09

    Hat das Label Ist kein Fehler hinzugefügt.
  • Ich gehe mal stark davon aus, dass das Problem der Suchindex für Beiträge ist

    Korrekt!

    (Ist das eigentlich überhaupt relevant, wenn elastic search genutzt wird?)

    Du kannst versuchen, den Query per MySQL auf der CLI (via SSH!) auszuführen, damit du nicht von den Laufzeitbeschränkungen des Webservers beeinträchtigt wirst

    Danke! Das werde ich morgen oder die Tage prüfen.

  • Nein, die Tabelle wird nicht aktiv verwendet, wenn Elasticsearch zum Einsatz kommt.

    Sollte die Systemprüfung dann nicht angepasst werden, dass dies nicht bemängelt wird, wenn Elasticsearch genutzt wird?

    Der Test via SSH hat sich jedenfalls erübrigt. Nun, am nächsten Morgen, ist diese Prüfung auf einmal erfolgreich, ohne dass ich noch etwas getan hätte. Als wäre das Ganze im Hintergrund, trotz Fehlermeldung, noch weitergelaufen.

  • Ist das eigentlich überhaupt relevant, wenn elastic search genutzt wird?

    Du kannst die Tagelle im übrigen Leeren (nicht löschen!).

    Sie hat bei verwendung von EL nur veraltete Daten und du musst den Suchindex eh neu aufbauen wenn du irgendwann von EL wieder zurück wechseln möchtest.

  • Sollte die Systemprüfung dann nicht angepasst werden, dass dies nicht bemängelt wird, wenn Elasticsearch genutzt wird?

    Der Test via SSH hat sich jedenfalls erübrigt. Nun, am nächsten Morgen, ist diese Prüfung auf einmal erfolgreich, ohne dass ich noch etwas getan hätte. Als wäre das Ganze im Hintergrund, trotz Fehlermeldung, noch weitergelaufen.

    Vielleicht hat der Webserver niedrigere Timeout-Werte als PHP. Dann durchaus möglich.

    • Offizieller Beitrag

    Hallo,

    Als wäre das Ganze im Hintergrund, trotz Fehlermeldung, noch weitergelaufen.

    das wundert mich nicht. Derartige DDL-Abfragen lassen sich, sobald sie einmal laufen, von einer Abbruch der Client-Verbindung typischerweise nicht beeindrucken. Irgendwann™ ist die Abfrage dann durchgelaufen und die Tabelle auf InnoDB umgestellt.

    Der Empfehlung von Morik kann ich mich aber anschließen: Du kannst den MySQL-Suchindex einfach leeren, dann wäre die Abfrage „zu sofort“ durchgelaufen.

    Sollte die Systemprüfung dann nicht angepasst werden, dass dies nicht bemängelt wird, wenn Elasticsearch genutzt wird?

    Nein, die Tabellen nutzen de facto die falsche Engine, auch wenn es zu dem gegebenen Zeitpunkt möglicherweise nicht relevant ist.

Jetzt mitmachen!

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