La mise à jour prend environ 20 minutes et la mise à jour de la progression se bloque (temporairement) à l'étape multisite:migrate

Soutien
1

J’ai effectué la mise à jour hebdomadaire de notre site Discourse et j’ai constaté qu’au lieu de prendre les 1 à 2 minutes habituelles, il a fallu environ 20 minutes cette fois-ci. De plus, la mise à jour de progression a temporairement échoué avec des erreurs de délai d’attente dans la console Chrome à l’étape $ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate (capture d’écran ci-dessous).

J’ai pu constater sur le serveur que quelque chose se passait (charge sur postmaster et occasionnellement sur ruby), et finalement les mises à jour de progression ont repris, mais dans l’ensemble, il semble y avoir un problème avec les migrations actuelles.

D’après les journaux de mise à jour, il semble que la migration responsable de la longue durée d’exécution était DropTrgmIndexesOnUsers. J’ai inclus la partie respective du journal directement dans ce message ci-dessous (le journal complet est joint sous forme de fichier texte au cas où il serait nécessaire pour une analyse plus approfondie).

image
image947×718 61.2 KB

********************************************************
*** Veuillez patienter, les prochaines étapes peuvent prendre un certain temps ***
********************************************************
...
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-bbcode est déjà à la dernière version compatible
discourse-data-explorer est déjà à la dernière version compatible
docker_manager est déjà à la dernière version compatible
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
Le migrator multisite s'exécute en utilisant 1 threads

Migration par défaut
== 20240912061702 DropUserSearchSimilarResultsSiteSetting: migration =========
-- execute("DELETE FROM site_settings WHERE name = 'user_search_similar_results';\n")
   -> 0.0006s
== 20240912061702 DropUserSearchSimilarResultsSiteSetting: migré (0.0015s) =

== 20240912061806 DropTrgmIndexesOnUsers: migration ===========================
-- 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: migré (1290.7169s) ===============

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

Initialisation par défaut
*** Bundling des assets. Cela prendra un certain temps *** 
$ bundle exec rake themes:update assets:precompile
Construction
Environnement : production
construction...
...

Journal complet : upgrade-log-2024-09-15.txt (124.7 Ko)

3

Je ne suis pas sûr qu’il y ait quoi que ce soit que nous puissions faire maintenant.

Nous devons supprimer l’index et si votre forum était très fréquenté à ce moment-là, cela peut prendre un certain temps.

Supposons que tout va bien maintenant ?

4

Oui, les choses sont de retour à la normale maintenant, donc pas de problème immédiat.

La principale raison pour laquelle je l’ai signalé ici était que l’indicateur de progression était temporairement cassé, et c’est peut-être quelque chose qui pourrait amener les gens à croire que la mise à jour a planté (pas sûr de ce qui peut vraiment être fait ici).

Ce ne fut pas le cas, cependant. Le serveur est un serveur de test (nous devons faire pas mal de préparation) et je lance généralement les mises à jour après minuit, donc je pense que j’étais probablement le seul utilisateur.

L’autre question qui m’est venue à l’esprit par la suite est donc : Discourse nécessite-t-il effectivement un SSD pour les communautés comme la nôtre (~6k utilisateurs, ~2,5M de messages) ? Parce que le serveur actuel est décent (AMD Ryzen 5 3600, 64 Go de RAM), mais il a des disques rotatifs classiques et si c’est un problème, nous devrons passer à un avec des SSD avant d’être en ligne.

5

Supprimer cet index sur un serveur comptant seulement 6 000 utilisateurs devrait prendre quelques millisecondes, même sur un disque dur mécanique ; c’est un fort indicateur que votre base de données manque de ressources.

6

Ok, merci ! Je n’étais pas au courant que l’optimisation de la base de données serait nécessaire (nous utilisons la configuration à conteneur unique) et il n’y a pas grand-chose d’autre qui tourne sur la machine (Discourse, Mailcow, Traefik, Crowdsec). Mais je vais y regarder de plus près.
Avez-vous des pistes vers la documentation pertinente à cet égard ? La seule chose que je connais pour le moment est Configure Discourse Docker on servers with more RAM and CPU, et notre db_shared_buffers est déjà à 4096MB.

7

Je soupçonne que cela est dû au fait que nous n’avons pas supprimé l’index de manière concurrente.

Un DROP INDEX normal acquiert un verrou ACCESS EXCLUSIVE sur la table, bloquant les autres accès jusqu’à ce que la suppression de l’index soit terminée.

Cela devrait être corrigé dans PERF: Update migration to drop index concurrently. by tgxworld · Pull Request #28955 · discourse/discourse · GitHub.

@schneeland Merci d’avoir pris le temps de signaler le problème :+1:

2 « J'aime »