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

1st Official Post
    Affected Version
    WoltLab Suite 5.4
    Affected 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:

    Quote

    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. ;)

    • Official Post

    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.

    Quote from Cadeyrn

    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.

    Quote from Alexander Ebert

    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?)

    Quote from Alexander Ebert

    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.

    Quote from Alexander Ebert

    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.

    Quote from Cadeyrn

    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.

    Quote from Cadeyrn

    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.

    • Official Post

    Hallo,

    Quote from Cadeyrn

    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.

    Quote from Cadeyrn

    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.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login