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

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

    "Wir finden Worte, die wie Geschosse treffen, wir leisten Schwüre, die niemals zerbrechen. Wir steh'n zusammen auch wenn man uns nicht mag, wir leben schneller, schneller in den Tag. Unsere Metaphern sind teuflische Ikonen, harte Aphorismen, gewagte Abstraktionen. Ein Strauß von Versen im Idiomenbeet, verbale Blüten wie es geschrieben steht."


    (Saltatio Mortis)

    • 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.


    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.

  • 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.

    "Wir finden Worte, die wie Geschosse treffen, wir leisten Schwüre, die niemals zerbrechen. Wir steh'n zusammen auch wenn man uns nicht mag, wir leben schneller, schneller in den Tag. Unsere Metaphern sind teuflische Ikonen, harte Aphorismen, gewagte Abstraktionen. Ein Strauß von Versen im Idiomenbeet, verbale Blüten wie es geschrieben steht."


    (Saltatio Mortis)

  • 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.

    "Wir finden Worte, die wie Geschosse treffen, wir leisten Schwüre, die niemals zerbrechen. Wir steh'n zusammen auch wenn man uns nicht mag, wir leben schneller, schneller in den Tag. Unsere Metaphern sind teuflische Ikonen, harte Aphorismen, gewagte Abstraktionen. Ein Strauß von Versen im Idiomenbeet, verbale Blüten wie es geschrieben steht."


    (Saltatio Mortis)

  • 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.

    • Official Post

    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.

Participate now!

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