L'aggiornamento richiede circa 20 minuti e l'avanzamento si interrompe (temporaneamente) al passaggio multisite:migrate

Supporto
1

Ho appena eseguito l’aggiornamento settimanale del nostro sito Discourse e ho scoperto che, invece dei soliti 1-2 minuti, questa volta sono stati necessari circa 20 minuti. Inoltre, l’aggiornamento dei progressi si è temporaneamente interrotto con errori di timeout nella console di Chrome al passaggio $ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate (screenshot sotto)

Ho potuto vedere sul server che stava succedendo qualcosa (carico su postmaster e occasionalmente su ruby) e alla fine gli aggiornamenti dei progressi sono ripresi, ma nel complesso sembra esserci un problema con le migrazioni attuali.

Dai log di aggiornamento, sembra che la migrazione responsabile del lungo tempo di esecuzione sia stata DropTrgmIndexesOnUsers. Ho incluso la parte relativa del log direttamente in questo post qui sotto (il log completo è allegato come file di testo nel caso fosse necessario per ulteriori analisi).

image
image947×718 61.2 KB

********************************************************
*** Please be patient, next steps might take a while ***
********************************************************
...
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-bbcode is already at latest compatible version
discourse-data-explorer is already at latest compatible version
docker_manager is already at latest compatible version
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
Multisite migrator is running using 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...
...

Log completo: upgrade-log-2024-09-15.txt (124.7 KB)

3

Non sono sicuro che ci sia qualcosa che possiamo fare ora.

Dobbiamo eliminare l’indice e se il tuo forum fosse molto attivo in quel momento, potrebbe volerci un po’.

Presumiamo che ora vada tutto bene?

4

Sì, le cose sono tornate alla normalità ora, quindi nessun problema immediato.

Il motivo principale per cui l’ho segnalato qui è che l’indicatore di avanzamento era temporaneamente rotto, e questo è forse qualcosa che potrebbe indurre le persone a credere che l’aggiornamento si sia bloccato (non sono sicuro di quanto si possa fare qui).

Questo però non è stato il caso. Il server è un server di test (dobbiamo fare un bel po’ di preparazione) e di solito eseguo gli aggiornamenti dopo mezzanotte, quindi penso di essere stato probabilmente l’unico utente.

Quindi l’altra domanda che mi è venuta in mente in seguito è: Discourse richiede effettivamente un SSD per community come la nostra (~6k utenti, ~2.5M post)? Perché il server attuale è decente (AMD Ryzen 5 3600, 64GB RAM), ma ha dischi rotanti classici e se questo è un problema, dovremo passare a uno con SSD prima di andare in produzione.

5

L’eliminazione di quell’indice su un server con soli 6.000 utenti dovrebbe richiedere millisecondi, anche su un disco rigido meccanico; è un forte indicatore che il tuo database è a corto di risorse.

6

Ok, grazie! Non ero a conoscenza del fatto che fosse necessaria l’ottimizzazione del DB (stiamo usando la configurazione a container singolo) e non c’è molto altro in esecuzione sulla macchina (Discourse, Mailcow, Traefik, Crowdsec). Ma darò un’occhiata più da vicino.
Ci sono indicazioni sulla documentazione pertinente a questo riguardo? L’unica cosa di cui sono a conoscenza al momento è Configure Discourse Docker on servers with more RAM and CPU, e il nostro db_shared_buffers è già a 4096MB.

7

Sospetto che ciò sia dovuto al fatto che non abbiamo eliminato l’indice in modo concorrente.

Un normale DROP INDEX acquisisce un blocco ACCESS EXCLUSIVE sulla tabella, bloccando altri accessi fino al completamento dell’eliminazione dell’indice.

Questo dovrebbe essere risolto in PERF: Update migration to drop index concurrently. by tgxworld · Pull Request #28955 · discourse/discourse · GitHub.

@schneeland Grazie per aver dedicato del tempo a segnalare il problema :+1:

2 Mi Piace