L'aggiornamento da /admin/upgrade richiede *molto* tempo

Bug
1

Durante l’aggiornamento di un singolo plugin da admin/upgrade ci vuole molto tempo.

Di solito una ricostruzione completa viene eseguita in circa 7 minuti.

È in fase di aggiornamento da 2023-03-02T20:07:00Z, lo stato attuale è:

image
image1209×628 171 KB

Output HTOP:

image
image927×202 48.7 KB

EDIT: 2023-03-02T20:44:00Z - ancora sulla stessa riga di log. CPU sempre la stessa. Ricostruzione CLI avviata a questo punto.

EDIT2: Per fare riferimento al tempo esatto impiegato da una ricostruzione sulla mia macchina, timestamp di completamento della ricostruzione: 2023-03-02T20:51:00Z

4 Mi Piace
2

Sì, sto riscontrando la stessa cosa almeno da ieri.

Ora è più o meno impossibile aggiornare dalla schermata di aggiornamento in tempi ragionevoli al momento, quindi si è costretti ad aggiornare dalla riga di comando.

3

Ricostruzione CLI completata.

Aggiornamento admin ancora bloccato e non sembra che il plugin sia stato aggiornato.

image
image386×168 6.51 KB

Ho cliccato su RESET UPGRADE e avviato un’altra cli-rebuild.

1 Mi Piace
4

Anche a me, ho esattamente la stessa cosa. Molto irritante quando si aggiornano i plugin, richiede davvero tanto tempo - estremamente scomodo.

2 Mi Piace
5

C’è qualche soluzione alternativa per questo? Ogni volta che aggiorno per stare al passo con le modifiche su Discourse Chatbot :robot: (Supports ChatGPT) - plugin - Discourse Meta, ci vuole così tanto tempo.

6

Questo è ancora un problema.

Tuttavia, sembra interessare solo i server con specifiche inferiori?

1 Mi Piace
9

Solo per aggiungere un’altra voce piuttosto che risposte… :slight_smile:

Ho un piccolo sito di test DO da 1 GB con molti plugin, quindi normalmente non è dei più veloci. Tuttavia, penso che ultimamente stia impiegando molto più tempo e il mio è stato bloccato in uno strano problema l’altro giorno, come @MarcP, e ho dovuto resettarlo.

Non l’ho mai cronometrato prima, ma oggi l’ho impostato su ‘Aggiorna tutto’ e ho preso nota di quando ho cliccato sul pulsante. Finora abbiamo iniziato alle 9:30 e sta ancora andando alle 10:15. Attualmente sta impacchettando alcuni asset. Posso dire con una certa sicurezza che normalmente non ci vogliono più di 45 minuti e contando per fare il suo lavoro.

Anche se sembra che abbia avuto alcuni problemi di permessi nel cancellare i file temporanei? Non sono sicuro se sia rilevante.

4 Mi Piace
11

@david e io abbiamo trovato la causa principale. (simile a quanto trovato da @Falco in passato)

Utilizziamo flag Ruby speciali per cercare di limitare la memoria durante gli aggiornamenti e questo non funziona più su Ruby 3.2.

Dovremmo avere a breve una PR per risolvere il problema.

7 Mi Piace
12
7 Mi Piace
13

Nota… affinché la correzione abbia effetto, c’è una piccola situazione “l’uovo prima della gallina”. Il vecchio codice viene ancora caricato quando si esegue l’aggiornamento.

Potrebbe essere necessario un ./launcher rebuild per la prima volta, e le volte successive l’aggiornamento web funzionerà.

Non c’è un modo semplice per aggirare questo problema. @cvx è un problema complicato… tecnicamente dovremmo fare in modo che DockerManager::Upgrader.new(user_id, repo, repo_version).upgrade esegua il shell e utilizzi il nuovo codice di aggiornamento quando aggiorna… ma è un vaso di Pandora.

Soluzione rapida

  1. Avviare l’aggiornamento del gestore docker
  2. Annullare quando si blocca
  3. Eseguire ./launcher restart app dalla shell
  4. L’aggiornamento dal web funzionerà.

Soluzione semplice

  1. Eseguire ./launcher rebuild app

Tutto andrà bene dopo questo.

EDIT

Chiudo questo in anticipo perché voglio che questo sia l’ultimo post su questo argomento. Ciò renderà facile per le persone trovare le soluzioni. Segnala per riaprire se il problema persiste dopo una ricostruzione.

8 Mi Piace