Ho una piccola istanza Discourse su un server con 25 GB di spazio. Al momento ne ha solo 3,4 GB liberi, e non sono sicuro del perché. Questo mi impedisce di eseguire gli aggiornamenti.
Non ci sono altri servizi in esecuzione su questa istanza oltre a Discourse, né ce ne sono mai stati.
Finora, per liberare spazio, ho:
eliminato tutti i log che sono riuscito a trovare, sia di Discourse che da /var/log/journal
eliminato tutti i backup di Discourse tranne uno
rimosso tutte le immagini Docker obsolete
eseguito apt-get autoclean e apt-get autoremove
verificato di non avere vecchi kernel
Ho pensato di spostare i dati di PostgreSQL su un disco esterno, ma al momento occupano meno di un GB, quindi non credo che questo aiuterà abbastanza.
/dev/vda1 sta utilizzando 20 GB di spazio.
C’è altro che posso fare? 25 GB non sono più una quantità ragionevole di spazio disco per eseguire Discourse?
Dipende principalmente dai tuoi upload, ma anche dai backup e da PostgreSQL se il tuo sito è molto grande (anche se sembra che non sia questo il problema). Quanto sono grandi i tuoi upload? La dashboard di amministrazione dovrebbe indicarlo in fondo.
È inferiore a 50 MB, quindi non si tratta affatto di un’istanza grande o vecchia. Come ho detto, ho pensato di spostarla dall’unità principale, ma non credo che questo sia il problema principale.
Se i tuoi upload sono di circa 25 MB e il tuo PostgreSQL è di circa 1 GB, sospetto che Discourse stia creando backup che non ti servono. Controlla le impostazioni di conservazione dei backup (Admin > Impostazioni > Backup) e dai un’occhiata ai tuoi backup attuali (Admin > Backup), eliminando quelli che non ti servono.
I maggiori utilizzatori di spazio nel filesystem sono /var/lib/containerd/io.containerd.content.v1.content con 2,4 GB e /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs con ben 12 GB
Mi dispiace, ho dimenticato di menzionare che devi essere all’interno del contenitore. Il file che hai menzionato proviene da Docker. Puoi verificare cosa lo sta utilizzando con docker system df ed eseguire un’eliminazione globale con docker system prune se necessario, assicurandoti solo che Discourse sia in esecuzione quando lo fai.
Nel container, l’unica cosa che supera un GB è /var/www/discourse/vendor/bundle/ruby/ a 2,1 GB.
Aggiungo che se eseguo il pruning dell’immagine scaricata durante l’aggiornamento, ho abbastanza spazio, ma quando provo ad aggiornare e la scarica di nuovo, lo perdo. Quindi quasi 5 GB di spazio sono necessari per la nuova immagine.
Infatti, per favore mostra tutti i tuoi output. Non consiglio di cercare all’interno del container - il tuo problema è a livello di sistema, ed è lì che devi iniziare a cercare. E non guardare dove pensi ci possa essere un problema, ma guarda il quadro generale.
Prima di tutto, riavvia. Vuoi un filesystem pulito e un sistema fresco.
Poi, guarda questo thread precedente per consigli dettagliati:
[quote=“Ed_S, post:3, topic:404122”]
Per favore pubblica i dettagli di ciò che è successo
[/quote]}
Il mio forum è piccolo (in realtà sono quasi solo io) e uso un VPS da 40 GB solo per stare tranquillo e non dover preoccuparmi che gli aggiornamenti mi causino mal di cuore.
È l’unico dei miei tre VPS che non utilizza 20 GB: gli altri sono un server HTTP con backend MySQL e PHP e un server RTMP. Quello che esegue Discourse esegue anche docker-mailserver, ma ho disattivato la digestione della posta e DMS ha un’impronta minima.
Grazie per le vostre risposte! Mi scuso per la scomparsa improvvisa: la vita mi ha travolto e ieri non ho avuto tempo di effettuare ulteriori controlli.
In sintesi, ho notato quanti thread ci siano su questo problema specifico e ho pensato che, anche se lo avessi risolto questa volta, sarebbe ricomparso, quindi ho trasferito la mia istanza su un server leggermente più grande con 35 GB di spazio disponibile.
Per chiunque stia cercando qui aiuto per questo stesso problema e non voglia effettuare un upgrade:
./launcher cleanup era qualcosa che avevo già provato, ma non ha liberato spazio sufficiente. Avevo già eseguito anche
E, ancora una volta, non è stato sufficiente. C’erano molti log (per una macchina da 25 GB) in journalctl, quindi controllate assolutamente se vale lo stesso per voi, ma nel mio caso non ha aiutato abbastanza.