Aggiornamento da 3.1.x a 3.2.0 si blocca/fallisce su istanza da 1GB

Installazione
22

Okay, posso capirlo. Non sarebbe possibile semplificare il processo di bootstrapping/compilazione per renderlo più lungo (CPU/serializzato) ma all’interno di risorse limitate (cioè RAM)?

1 Mi Piace
23

Penso che sarebbe un’ottima idea. E una ragione è questa: se non si riesce a ricostruire su un server minuscolo, allora non si può installare su un server minuscolo. E se si installa su un server di medie dimensioni, non si creerà il file di swap che sarà necessario sul server minuscolo. (Idealmente lo script di installazione creerebbe comunque il file di swap, e imposterebbe anche le due impostazioni del kernel che dovrebbero essere impostate.)

24

Anche questa è un’ottima idea. Nello stesso modo in cui idealmente un processo di ingegneria del software monitora i tempi di compilazione, altrimenti i tempi di compilazione diventano sempre più lunghi, per Discourse il processo dovrebbe idealmente testare e monitorare l’installabilità su piccole istanze. Rendilo un obiettivo.

1 Mi Piace
25

Ho sperimentato la creazione di immagini avviate autonomamente che migrano e precompilano asset al lancio (con impostazioni ENV per saltare tali attività). Questo funziona per lo più (non tanto per siti enormi e per cose che dipendono dal fatto che il lancio avvenga in un certo lasso di tempo).

Tuttavia, questi dipendono dall’esistenza di redis e postgres.

Con un’installazione di 2 container per lo più standard, potrebbe essere possibile farla funzionare per lo più.

Ooooooooooooooooooooooh, ma la precompilazione degli asset, immagino, sia il passaggio che causa i problemi. . .

26

Sto leggendo di questo aggiornamento di Ember 5 che sta attraversando il sistema. Che impatto avrebbe sulle risorse di compilazione?

27

Penso che la documentazione necessiti di un aggiornamento, discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

  • La RAM predefinita di 1 GB funziona bene per le piccole community di Discourse.

1 GB non è più un’opzione. Il requisito minimo è 2 GB per creare discourse.

1 Mi Piace
28

Ho un sacco di siti che ho aggiornato di recente con 1 GB di RAM. Ho aumentato il loro swap a 3 o 4 GB, però.

Certamente non lo consiglio, ma per alcune persone è un enorme ostacolo economico e se la cavano. Ma forse “funziona bene” è un’esagerazione.

3 Mi Piace
29

Sì, forse specificare che 1 GB di RAM + 4 GB di swap. È fallito con uno swap di 2 GB.

30

Hai qualche plugin? Molti temi?

31

9 plugin e solo 1 tema. Ancora tutto questo ha funzionato alla grande fino alla versione 3.1.x con 1 GB di RAM e 2 GB di swap (era un po’ lento, forse 20 minuti per ricostruire ma ha sempre funzionato)
Tentando di aggiornare alla versione 3.2.0 è fallito costantemente (vedi sopra).

32

Sì. Sicuramente nessun plugin con 1 GB di RAM. Sembra qualcosa da aggiungere alla documentazione di installazione.

Sarei interessato a sapere se ha funzionato senza i plugin.

33

Come abbreviazione estrema posso capire perché lo dici, ma non sei d’accordo che il via libera/stop per eseguire Discourse sia RAM+swap? 1+3 è buono quanto 2+2 dal punto di vista del via libera/stop.

È solo la performance (reattività) a cui importa quanta RAM hai.

RAM+swap è la cosa giusta da controllare e testare. Memoria=RAM+swap.

A proposito, se qualcosa non funziona senza un’evidente ragione e soprattutto se sospetti una carenza di memoria, vale la pena controllare l’out-of-memory killer, noto anche come OOM-killer. Raccomando

dmesg|egrep -i "memory|oom|kill"

Modifica: per comodità aggiungerò questo al mio elenco di diagnostica istantanea standard:

cat /etc/lsb-release
uptime
df -h /
free
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc
5 Mi Piace
34

Ho riscontrato lo stesso problema, ma non durante un aggiornamento, bensì durante l’esecuzione di una nuova installazione della versione 3.2.0.

Sto usando AWS EC2, proprio come @RBoy.

Sto cercando una soluzione per installare la versione 3.1.5 invece della 3.2.0, poiché il vecchio forum non ha fornito alcuna assistenza.

AGGIORNAMENTO:

scusate, ho trovato questo:

1 Mi Piace
35

Sarei molto interessato a sapere se sei riuscito a fare un’installazione pulita di 3.1.5 utilizzando il metodo del tag menzionato nel tuo link. Per favore, rispondi se ci provi.

Per quanto riguarda l’installazione di 3.2.0 su un sistema da 1 GB, potresti provare questo: imposta la dimensione dello SWAP a 8 GB e vedi se funziona. Probabilmente sarà MOLTO LENTO ma potrebbe funzionare.

36

Grazie per la tua preziosa guida.

Recentemente ho completato una nuova installazione della versione Docker di Discourse 3.15 e volevo condividere quanto sia stato semplice il processo, specialmente per chi utilizza il livello gratuito di AWS EC2, come me.

Ecco una guida concisa basata sulla mia esperienza:

  1. Naviga al tuo file di configurazione di Discourse situato in /var/discourse/containers/app.yml.

  2. Nella sezione params, aggiorna il parametro version per corrispondere alla versione desiderata di Discourse. Ad esempio:

    params:
  # ...
  ## Specifica la revisione Git per questo container (default: tests-passed)
  version: v3.1.5 # Usa qui il nome del tag specifico

  3. Salva le modifiche ed esci dall’editor. Quindi, esegui il seguente comando per ricostruire la tua applicazione Discourse:

    /var/discourse/launcher rebuild app

Il processo ha funzionato perfettamente per me, dimostrando che mantenere una configurazione di Discourse a basso costo o addirittura a budget zero è del tutto fattibile.

Spero che questa guida aiuti altri che cercano di gestire le proprie installazioni di Discourse in modo efficiente ed economico.

2 Mi Piace