Update dauert etwa 20 Minuten und Fortschrittsupdates unterbrechen (vorübergehend) bei Schritt multisite:migrate

Unterstützung
1

Ich habe gerade das wöchentliche Update für unsere Discourse-Site durchgeführt und festgestellt, dass es diesmal etwa 20 Minuten gedauert hat, anstatt der üblichen 1-2 Minuten. Außerdem gab es bei der Fortschrittsanzeige vorübergehend Timeout-Fehler in der Chrome-Konsole bei Schritt $ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate (Screenshot unten).

Ich konnte auf dem Server sehen, dass etwas passierte (Auslastung bei Postmaster und gelegentlich bei Ruby), und schließlich erholte sich die Fortschrittsanzeige, aber insgesamt scheint es ein Problem mit den aktuellen Migrationen zu geben.

Aus den Update-Logs geht hervor, dass die Migration, die für die lange Laufzeit verantwortlich war, DropTrgmIndexesOnUsers war. Ich habe den entsprechenden Teil des Logs direkt in diesen Beitrag unten aufgenommen (das vollständige Log ist als Textdatei beigefügt, falls es für weitere Analysen benötigt wird).

image
image947×718 61.2 KB

********************************************************
*** Bitte haben Sie Geduld, die nächsten Schritte können eine Weile dauern ***
********************************************************
...
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-bbcode ist bereits in der neuesten kompatiblen Version
discourse-data-explorer ist bereits in der neuesten kompatiblen Version
docker_manager ist bereits in der neuesten kompatiblen Version
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
Multisite Migrator läuft mit 1 Threads

Migrating default
== 20240912061702 DropUserSearchSimilarResultsSiteSetting: migrating ==========
-- execute("DELETE FROM site_settings WHERE name = 'user_search_similar_results';\n")
   -> 0.0006s
== 20240912061702 DropUserSearchSimilarResultsSiteSetting: migrated (0.0015s) =

== 20240912061806 DropTrgmIndexesOnUsers: migrating ===========================
-- execute("DROP INDEX IF EXISTS index_users_on_username_lower_trgm;\nDROP INDEX IF EXISTS index_users_on_name_trgm;\n")
   -> 1290.7163s
== 20240912061806 DropTrgmIndexesOnUsers: migrated (1290.7169s) ===============

== 20240912212253 IncreaseExternalAvatarUrlLimitTo2000: migrating =============
-- change_column(:single_sign_on_records, :external_avatar_url, :string, {:limit=>2000})
   -> 0.0011s
== 20240912212253 IncreaseExternalAvatarUrlLimitTo2000: migrated (0.0017s) ====

Seeding default
*** Bundling assets. This will take a while *** 
$ bundle exec rake themes:update assets:precompile
Building
Environment: production
building...
...

Vollständiges Log: upgrade-log-2024-09-15.txt (124.7 KB)

3

Ich bin mir nicht sicher, ob wir jetzt noch etwas tun können.

Wir müssen den Index löschen, und wenn Ihr Forum zu dieser Zeit sehr stark besucht war, kann dies eine Weile dauern.

Gehen wir davon aus, dass jetzt alles in Ordnung ist?

4

Ja, die Dinge sind jetzt wieder normal, also kein unmittelbares Problem.

Der Hauptgrund, warum ich es hier gemeldet habe, war, dass der Fortschrittsanzeiger vorübergehend defekt war, und das könnte Leute vielleicht glauben lassen, dass das Update abgestürzt ist (ich bin mir nicht sicher, wie viel man hier wirklich tun kann).

Das war jedoch nicht der Fall. Der Server ist ein Testserver (wir müssen viel vorbereiten) und ich führe Updates normalerweise nach Mitternacht durch, daher war ich wahrscheinlich der einzige Benutzer.

Daher ist die andere Frage, die mir danach in den Sinn kam: Benötigt Discourse effektiv eine SSD für Communities wie unsere (~6.000 Benutzer, ~2,5 Millionen Beiträge)? Denn der aktuelle Server ist anständig (AMD Ryzen 5 3600, 64 GB RAM), aber er hat klassische rotierende Festplatten, und wenn das ein Problem ist, müssten wir vor dem Livegang auf einen mit SSDs umsteigen.

5

Das Entfernen dieses Indexes auf einem Server mit nur 6.000 Benutzern sollte Millisekunden dauern, selbst auf einer rotierenden Festplatte; es ist ein starker Hinweis darauf, dass Ihre Datenbank unter Ressourcenmangel leidet.

6

Ok, danke! Mir war nicht bewusst, dass eine DB-Optimierung erforderlich sein würde (wir verwenden die Single-Container-Einrichtung) und es läuft nicht viel anderes auf der Maschine (Discourse, Mailcow, Traefik, Crowdsec). Aber ich werde es mir genauer ansehen.

Gibt es Hinweise auf relevante Dokumentation in dieser Hinsicht? Das Einzige, was mir im Moment bekannt ist, ist Configure Discourse Docker on servers with more RAM and CPU, und unser db_shared_buffers ist bereits auf 4096MB eingestellt.

7

Ich vermute, das liegt daran, dass wir den Index nicht gleichzeitig gelöscht haben.

Ein normales DROP INDEX erwirbt einen ACCESS EXCLUSIVE-Lock auf der Tabelle, der andere Zugriffe blockiert, bis der Index-Drop abgeschlossen werden kann.

Dies sollte in PERF: Update migration to drop index concurrently. by tgxworld · Pull Request #28955 · discourse/discourse · GitHub behoben sein.

@schneeland Danke, dass du dir die Zeit genommen hast, das Problem zu melden :+1:

2 „Gefällt mir“