Aggiornamento 2.6.0 beta 3 fallito su spazio su disco e/o memoria

Mi chiedo se, oltre ai problemi di spazio su disco, il processo di aggiornamento abbia superato la memoria disponibile (1 GB) allocata al droplet. Nella screenshot della console sopra riportata si può vedere un riferimento a ‘Out of memory’ come primo elemento registrato dopo l’esecuzione di ./launcher rebuild app.

Quello che non ho menzionato è che, dopo quel tentativo, la console ha smesso di rispondere (anche se in quel momento stavo usando la console basata sul web nel pannello di controllo di Digital Ocean, che è sempre instabile), e ho quindi riavviato il droplet. (Da quel momento ho utilizzato PuTTY).

In ogni caso, non è affatto bene che l’aggiornamento sia stato segnalato come riuscito tramite la pagina di aggiornamento di Discourse dopo aver presumibilmente riscontrato lo stesso problema di memoria e/o disco.

2 Mi Piace

Ah, il killer OOM è entrato in azione. Di certo non è una buona notizia. Normalmente consiglierei di aumentare lo spazio di swap. Puoi visualizzare l’utilizzo corrente con swapon; nel mio caso:

# swapon
NAME      TYPE SIZE USED PRIO
/swapfile file   2G   3M   -2

Anche free:

# free
              total        used        free      shared  buff/cache   available
Mem:        1992060      792904       80148       34696     1119008     1004956
Swap:       2097148        3084     2094064

Sarebbe grave se il tuo file di swap da 2G non fosse attivo. È negativo non poter aggiungere swap senza utilizzare spazio su disco!

Un modo per liberare spazio su disco per un aggiornamento è copiare tutti i file di backup su un sito esterno, verificarne l’integrità e poi cancellarli dal server. Hai assolutamente bisogno di un backup recente e affidabile in un luogo sicuro durante un aggiornamento, nel caso di imprevisti, ma non deve necessariamente risiedere sul server stesso. Mi sentirei a mio agio nel cancellare tutti i backup tranne l’ultimo, ma farei senz’altro una copia offline.

Sarebbe utile vedere di nuovo i risultati di du, ora che hai completato tutte le pulizie.

2 Mi Piace

Mi chiedo: i 1 GB sono la tua allocazione RAM e i 25 GB la tua allocazione del disco? Due cose molto diverse.

Modifica: la storia standard supportata, credo, sia di avere piuttosto più di 1 GB di RAM.
Modifica: no, a quanto pare 1 GB è ancora il minimo assoluto consigliato.

2 Mi Piace

Ho appena ricollegato, e le informazioni di sistema riportate all’avvio della finestra della console sono:

Carico di sistema:  0.01               Processi:              136
Utilizzo di /:   59,4% di 24,06 GB   Utenti con sessione attiva:        0
Utilizzo memoria: 73%                Indirizzo IP per eth0:    159.65.140.176
Utilizzo swap:   17%                Indirizzo IP per docker0: 172.17.0.1

Quindi lo spazio swap al 17% corrisponde a 4 GB?
Senza nessuno connesso al forum e con solo la connessione PuTTY corrente al droplet attiva, la RAM è piena al 73%: quindi sembra che basterebbe poca attività per spingere il forum a utilizzare lo spazio swap. Se questo spazio viene prelevato dai 24 GB, forse si crea la tempesta perfetta durante un aggiornamento, dato che l’utilizzo del disco è già elevato?

du -kx / | sort -n | tail -33 ora mi restituisce:

root@nz:~# du -kx / | sort -n | tail -33
505512  /usr/bin
528784  /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor/bundle/ruby/2.6.0
528788  /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor/bundle/ruby
528792  /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor/bundle
536848  /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor
548952  /var/lib/docker/overlay2/c126267f944d8d7f12415ac4f5908eba8a6a686b093cad3e0115eded8edfd6ba/diff
548968  /var/lib/docker/overlay2/c126267f944d8d7f12415ac4f5908eba8a6a686b093cad3e0115eded8edfd6ba
817700  /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/usr/lib
827812  /var/log/journal/8bebc832e1a692c83690ffe65e1256e3
868792  /var/log/journal
1069356 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse
1069368 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www
1069396 /var/log
1142352 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var
1202004 /var/discourse/shared/standalone/import/data
1307816 /var/discourse/shared/standalone/import
1362804 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/usr
1399332 /var/discourse/shared/standalone/backups/default
1399336 /var/discourse/shared/standalone/backups
1709408 /usr
2438224 /var/discourse/shared/standalone/postgres_data/base/16583
2462944 /var/discourse/shared/standalone/postgres_data/base
2481288 /var/discourse/shared/standalone/postgres_data
2540188 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff
2540204 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35
3387776 /var/lib/docker/overlay2
3460136 /var/lib/docker
3830584 /var/lib
5629420 /var/discourse/shared/standalone
5629504 /var/discourse/shared
5632224 /var/discourse
10747244        /var
14961492        /
root@nz:~#
1 Mi Piace

Penso che tu possa migliorare questa situazione con journalctl, magari usando

# journalctl --vacuum-size=50M

(che potresti eseguire immediatamente prima di tentare un aggiornamento)

È interessante notare che l’utilizzo di PostgreSQL non è diminuito.

Il comando free ti mostrerà l’utilizzo dello swap: è al 17%, su una quantità totale che probabilmente è di 2 GB.

È evidente che la tua macchina è un po’ troppo piccola per le tue esigenze: hai bisogno di più RAM o di più swap, e non puoi praticamente aumentare ulteriormente lo swap senza avere più spazio su disco.

1 Mi Piace

Scusa - hai perfettamente ragione. I 1 GB erano la RAM, non lo spazio su disco utilizzato.

1 Mi Piace

Ancora una volta hai perfettamente ragione

root@nz:~# free
              total        used        free      shared  buff/cache   available
Mem:        1008828      655660       61716      102288      291452       96576
Swap:       2097148      459776     1637372

Mi chiedo se il processo di aggiornamento dovrebbe valutare la capacità del sistema host per implementare l’aggiornamento proprio prima di avviarlo?

2 Mi Piace

Penso che sia in qualche modo nella categoria di prevedere il futuro! Il controllo per 5G di spazio su disco è chiaramente utile, ma non sarà ermetico. La RAM libera è più difficile da valutare, è piuttosto sfuggente quanto sarà necessario. Sarà una funzione, penso, di quanto grande è diventato il forum e forse anche di cosa deve essere toccato durante ogni aggiornamento.

Sono attento a minimizzare i costi, quindi dedicherò tempo a cercare di rientrare in un server economico. Ma alla fine, man mano che un forum cresce, varrà sicuramente la pena passare al livello successivo. E questo costerà denaro, ma farà risparmiare tempo e sforzi.

2 Mi Piace

Sono purtroppo molto vicino all’estremo del ‘minimizzare i costi’ - il forum è un’attività puramente volontaria che non genera entrate e, con l’aggiunta della possibilità di pubblicare tramite email (tramite MailGun) richiesta dagli utenti, può costarmi un po’ ogni mese per mantenerlo attivo.

Tra i passatempi, immagino sia più economico rispetto a bere nei locali notturni!

6 Mi Piace

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.