L'intera macchina si blocca durante l'aggiornamento

Installazione
1

Da quando ho provato i plugin AI (e poi li ho rimossi di nuovo), la mia macchina si blocca completamente durante /admin/upgrade.

Non sempre, ma circa l’80% delle volte.

Di solito la mia intera istanza EC2 si blocca e devo eseguire un riavvio forzato tramite l’interfaccia web EC2 di AWS.

Oggi si blocca di nuovo. Con mia sorpresa, non si blocca completamente. Aprendo l’URL principale ora mostra:

Oops

Il software che alimenta questo forum di discussione ha riscontrato un problema imprevisto. Ci scusiamo per l’inconveniente.

Informazioni dettagliate sull’errore sono state registrate e generata una notifica automatica. Ci daremo un’occhiata.

Non è necessaria alcuna ulteriore azione. Tuttavia, se la condizione di errore persiste, è possibile fornire ulteriori dettagli, inclusi i passaggi per riprodurre l’errore, pubblicando un argomento di discussione nella categoria di feedback del sito.

Ora proverò a riavviarlo di nuovo e a fare la solita procedura sudo ./launcher rebuild app che finora lo ha risolto. Incrociamo le dita che lo faccia anche oggi.

La mia domanda

Qualcuno può darmi qualche suggerimento su dove potrei controllare i file di log o cose simili per ottenere almeno un messaggio di errore sul perché si verificano i blocchi?

2

Il plugin AI ufficiale?

Lo eseguirei dalla console e vedrei dove si blocca, condividi i log.

1 Mi Piace
3

Sì, il plugin ufficiale.

L’ho disinstallato rimuovendo nuovamente i plugin da app.yml e poi ricostruendo. Forse questo non è sufficiente?

Cosa si intende con “questo”? Il sudo ./launcher rebuild app?

1 Mi Piace
4

Qual è la configurazione del tuo server?

Gli aggiornamenti online, secondo me, richiedono ormai un server da 4 GB + 2 GB di swap come minimo.

2 Mi Piace
5

Sto utilizzando un’istanza AWS EC2 “t2.medium” con 2 vCPU e 4 GiB di RAM.

L’HDD è di 100 GiB con 60 GiB di spazio libero.

Se può essere d’aiuto, posso aggiornare “t2.medium” a un tipo di istanza più grande.

Sono solo confuso dal fatto che questa configurazione ha funzionato in modo impeccabile (per anni) prima del mio test del plugin AI ufficiale e solo da allora, dopo averlo rimosso, si verificano questi blocchi durante l’aggiornamento.

1 Mi Piace
6

È cambiata un’altra cosa: la versione del software a cui stai aggiornando. Ultimamente ha iniziato a richiedere più memoria. Quindi penso che potrebbe essere una delle due cose.

Un aggiornamento temporaneo e reversibile a un’istanza con più RAM è probabilmente il modo più semplice per testare se la carenza di memoria è il problema, anche se comporta un paio di riavvii. L’altro modo è aggiungere lo swap, che è anch’esso reversibile.

3 Mi Piace
7

Proverei ad aggiungere lo swap.

2 Mi Piace
8

Grazie ragazzi, cercherò su Google come fare e poi lo farò :slight_smile:.

Aggiornamento 1

Ora ho aggiunto 8 GiB di swap:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       290Mi       2.9Gi       1.0Mi       677Mi       3.3Gi
Swap:          8.0Gi          0B       8.0Gi

Pubblicherò un aggiornamento qui dopo alcuni prossimi aggiornamenti per vedere se questo ha aiutato.

Aggiornamento 2

Ho appena eseguito un /admin/upgrade e monitorato l’utilizzo della RAM:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.4Gi       1.5Gi        50Mi       891Mi       2.0Gi
Swap:          8.0Gi       200Mi       7.8Gi

E l’aggiornamento è andato a buon fine. :tada: Spero che rimanga così.

Aggiornamento 3

Diversi giorni e aggiornamenti dopo, non ho più riscontrato blocchi.

Quindi penso che lo swap sia stata la soluzione. Grazie ancora a chiunque mi abbia aiutato con questo problema.

2 Mi Piace
9

Questo è un po’ fuori tema, ma vorrei davvero capire. Perché lo swap, che ha usato 200 MB, ha aiutato quando c’erano 2 GB di RAM liberi?

(Capisco che nel mondo degli pollici il sistema SI possa essere confusionario perché usa una scala di 10, ma perché diavolo Mi? Posso in qualche modo capire Gi se è abbreviato da giga, ma mega dovrebbe allora essere Me?)

1 Mi Piace
10

Mi per Mibibyte immagino, e Gi per Gibibyte.

1 Mi Piace
11

Grazie. Non lo sapevo, ovvio. Ma è mebibyte :wink:

E per gli altri che non lo sapevano nemmeno :smirking_face:

2 Mi Piace
12

Penso che il problema originale fosse probabilmente un processo che veniva terminato perché la macchina era a corto di memoria (attenzione all’OOM killer). L’aggiunta dello swap ha fatto sì che la memoria non si esaurisse. Quei due output di free potrebbero non raccontare tutta la storia, a meno che non siano stati presi con molta attenzione nel momento di maggiore stress della macchina. Penso che sia l’utilizzo massimo dello swap ad essere interessante.

Ma c’è anche la questione del parametro del kernel come menzionato in
MKJ’s Opinionated Discourse Deployment Configuration
che ho impostato correttamente, ma che forse molte persone non hanno impostato correttamente.

Vale la pena notare che il memory overcommit non ha molto a che fare con Redis. È solo che Redis è abbastanza gentile da suggerire che dovrebbe essere impostato correttamente.

3 Mi Piace
13

Ho appena avviato un altro /admin/upgrade e ho aperto una shell per chiamare manualmente tree -h circa ogni secondo.

I valori di utilizzo della memoria più alti che ho potuto trovare sono stati questi:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       3.2Gi       120Mi        80Mi       542Mi       266Mi
Swap:          8.0Gi       276Mi       7.7Gi

L’aggiornamento è riuscito.

1 Mi Piace
14

Quindi 4 GB sono al limite al momento della compilazione, se supponiamo che l’ultimo screenshot mostri il momento più stressante.

E questa è un’altra cosa che non riesco a capire: perché altri hanno poca memoria e io, che uso molti plugin e componenti, non ho avuto problemi :thinking: cosa fa la differenza?

E ho usato ho avuto perché ormai ho 8 GB grazie all’IA (e per me la differenza di prezzo non era così importante, ma questa è un’altra storia).

Questo thread dovrebbe spostarsi altrove o stiamo vedendo questo come una spiegazione del perché l’uso dello swap ha aiutato?

Comunque. Per altri principianti, questo è un esempio in cui si parla un po’ di poca memoria e delle ragioni per questo:

Questa è una domanda fortemente FAQ quando l’aggiornamento fallisce. Ma la ragione per questo è raramente spiegata.

1 Mi Piace
15

@Jagster @uwe_keim potreste per favore segnalare l’output di questi comandi

cat /proc/sys/vm/overcommit_memory 
cat /sys/kernel/mm/transparent_hugepage/enabled

Sui miei sistemi ho

# cat /proc/sys/vm/overcommit_memory 
1
# cat /sys/kernel/mm/transparent_hugepage/enabled 
always madvise [never]
1 Mi Piace
16 
$ cat /proc/sys/vm/overcommit_memory
0

e

$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
1 Mi Piace
17

Grazie @uwe_keim - Supporrò che quelle configurazioni del kernel siano il motivo per cui hai dovuto aggiungere lo swap, anche se non sembrava essere utilizzato. (Lo stesso varrebbe se avessi dovuto aggiungere molta RAM, perché la memoria totale disponibile è RAM+swap.)

1 Mi Piace
18

Posso modificare le impostazioni del server in qualsiasi momento se me lo consigli.

19 
root@foorumi-hel:/var/discourse# cat /proc/sys/vm/overcommit_memory
0
root@foorumi-hel:/var/discourse# cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
2 Mi Piace
20

¡Lo recomiendo!

Esto lo solucionará para futuros reinicios (ten en cuenta que sobrescribe archivos sin comprobar el estado actual):

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system
1 Mi Piace