Picco di utilizzo del disco durante il backup, Discourse è crashato duramente :-(

Supporto Installazione
1

Questa mattina intorno alle 5:35, i miei forum hanno improvvisamente registrato un picco nell’utilizzo del disco e si sono bloccati, andando completamente offline. Ho dovuto ridimensionare l’immagine di Digital Ocean per rimetterli in piedi. Oof.

Ecco l’utilizzo del disco nelle ultime 24 ore:

image
image2050×698 35.8 KB

Domanda: che tipo di log o analisi post-mortem posso esaminare per capire cosa diavolo è successo?! Ho controllato i log nel pannello di controllo di Discourse, ma non ci sono indizi… si interrompono semplicemente quando il sito si è bloccato e riprendono subito dopo quando è tornato online.

1 Mi Piace
2

Inizierei individuando quale directory sta causando il problema. Il mio approccio standard è entrare in /var/discourse e poi eseguire du -h -d 1. Prendi la directory più grande, entra al suo interno e ripeti finché non trovi il colpevole. Una volta individuato, questo potrebbe darti un indizio su cosa sta succedendo.

3 Mi Piace
3

Magari un backup automatico?

3 Mi Piace
4

Sì, i backup sono una causa comune di questo tipo di errore: come appare l’utilizzo del disco in una finestra di 7 giorni?

Tieni anche presente che i caricamenti locali sono inclusi in questi backup, quindi se hai avuto un aumento significativo dei caricamenti intorno alle 18:00, ciò avrebbe anche aumentato la dimensione dell’archivio di backup.

5 Mi Piace
5

Hmm. Sto trasferendo i file da S3 al mio server locale, ma il processo sembra essere eseguito in tempo reale e gestisce solo alcune centinaia di immagini alla volta (circa 300 kB ciascuna) = ~0,1 GB per batch. Nell’ultima settimana, potrei aver eseguito lo script 20 volte, quindi 20 batch = circa 2 GB di spazio su disco in totale. Avevo comunque molto spazio disponibile.

C’è la possibilità che, anche se lo script sembra spostare i file in tempo reale (scaricandoli da S3 e caricandoli immediatamente su Digital Ocean), esista anche un qualche tipo di ritardo per un’attività in coda che si sarebbe attivata alle 5:30, relativa allo spostamento di queste immagini?

(Inoltre: stavo eseguendo questi batch manualmente fino alle 21:00, quindi per quanto ne so, il server stava solo eseguendo operazioni normali dalle 21:00 alle 5:30, quando si è bloccato.)

Ecco il mio utilizzo del disco negli ultimi 7 giorni. Era in costante aumento a causa delle immagini importate, ma si può vedere dove è arrivato al 100% alle 5:30:

image
image2158×688 47.9 KB

Ci sono file di log che potrebbero fornire indizi su cosa è successo alle 5:35, oltre a quelli che vedo nella scheda ‘Log’?

1 Mi Piace
6

Hmm. I backup sono configurati per andare su S3 ogni 2 giorni, ma niente dal 9?

image
image1694×856 73.4 KB

Vista ‘Backup’ di Discourse

image
image1702×744 38.3 KB

Vista Amazon S3

image
image1586×482 68.6 KB

A proposito, dopo aver visto quanto sopra, ho cliccato sul pulsante in Discourse per attivare un backup. Ci sono voluti 28 minuti e sembra sia andato a buon fine; ora vedo quel file .tar.gz sia nella vista dei backup di Discourse che in quella di Amazon S3. Allora perché i miei backup automatici non si attivano?! Arggggh.

7

Sono perplesso… nessuna di queste è particolarmente grande:

root@x-app:/var/www/discourse# du -h -d 1

3.5M	./lib
104K	./bin
8.0K	./.tx
148M    ./public
8.0K	./.bundle
14M     ./plugins
4.3M	./db
4.0K	./log
532M	./tmp
8.9M	./spec
17M     ./config
556M	./vendor
8.0K	./images
329M	./.git
2.0M	./script
80K	    ./docs
2.5M	./test
16K	    ./.github
17M	    ./app
1.6G	.

E anche guardando lo spazio su disco complessivo all’interno del contenitore Docker, non è grande come prima. Avevo un droplet DigitalOcean da 80 GB, ed è quello che ha raggiunto il 100%. Quindi l’ho ridimensionato a 160 GB, raddoppiandolo. In teoria, questo significa che una di queste directory dovrebbe essere al 50%, giusto?

root@x-app:/var/www/discourse# df -h

Filesystem      Size  Used Avail Use% Mounted on
overlay         155G   58G   98G  38% /
tmpfs            64M     0   64M   0% /dev
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
shm             512M  2.6M  510M   1% /dev/shm
/dev/vda1       155G   58G   98G  38% /shared
tmpfs           3.9G     0  3.9G   0% /proc/acpi
tmpfs           3.9G     0  3.9G   0% /proc/scsi
tmpfs           3.9G     0  3.9G   0% /sys/firmware
8

Hai raggiunto picchi vicini al 100% quasi ogni notte in passato — sembra che questa volta ti abbia fatto superare il limite. Mi aspetto che i backup precedenti siano falliti per mancanza di spazio durante la creazione del file di backup locale da inviare a S3, ma siano falliti semplicemente senza rompere il tuo forum. Hai finalmente notato il problema quando la mancanza di spazio ha reso PostgreSQL (o Redis, o altro, non è davvero importante) instabile proprio nel momento giusto per far cadere il tuo forum.

(Con quasi 100 GB di immagini sul mio server, eseguo backup programmati di Discourse senza gli upload, ma con le miniature. Poi eseguo un backup basato su file con offset della directory dei backup prima e della directory degli upload dopo. Ho testato questo metodo per il ripristino; è stato la base per una migrazione del sito che ho effettuato l’anno scorso. Archiviare tarball da 100 GB ogni notte sarebbe folle.)

7 Mi Piace
9

Aha, quindi quei piccoli picchi sono Discourse che sta cercando di eseguire un backup! Questo chiarisce alcune cose.

Ecco di nuovo il mio grafico degli ultimi 7 giorni.

image
image2158×688 47.9 KB

Forse ciò che stiamo osservando è:

  1. Più volte nel corso dell’ultima settimana, Discourse ha tentato di eseguire un backup. Questo processo consuma temporaneamente molta spazio su disco e, ogni volta che ci ha provato, ha esaurito lo spazio disponibile, quindi nessuno di quei backup è andato a buon fine.

  2. Poi, quando ha riprovato ieri sera a eseguire un backup, è arrivato più avanti nel processo, ma purtroppo ha fatto crashare il sito.

Ha senso, dato che l’ultimo backup riuscito era del 9 luglio. Quindi ha atteso 2 giorni (secondo le mie impostazioni) e ha riprovato il 11 luglio. Quel tentativo è fallito, quindi ha atteso 24 ore e ha riprovato il 12, il 13 e il tentativo fatale il 14.

Se è davvero questo ciò che è successo, mi piacerebbe vedere:

  1. Notifiche migliori da parte di Discourse quando un backup fallisce

  2. Forse Discourse dovrebbe automaticamente “fallire” un backup (creando una notifica) se, all’inizio del processo, c’è meno di x% (10%?) di spazio libero su disco. In questo modo non inizierebbe nemmeno se lo spazio su disco è già insufficiente.

A proposito, se è davvero successo questo, guardando il primo backup fallito, quello del 11 luglio, si nota che c’era circa il 40% di spazio libero su disco (che sarebbero stati circa 32 GB!!!), ma non era sufficiente per completare con successo il backup. È corretto?! Perché Discourse avrebbe bisogno di una quantità così eccessiva di spazio temporaneo/lavorativo durante la creazione di un backup?

2 Mi Piace
10

Non è necessariamente andato più avanti la scorsa notte; hai semplicemente “perso una corsa” — ciò che accade quando lo spazio si esaurisce dipende da quale componente viene colpito per primo dal problema.

Se non riesce a creare un backup, mi aspetto che possa tentare di inviare un messaggio, ma se non c’è spazio sul disco, potrebbe non riuscire. :scream:

Una percentuale fissa non dice molto; il database potrebbe essere minuscolo rispetto ai caricamenti, o viceversa, e ci sono variabili come l’inclusione delle miniature e dei caricamenti. Immagino che si potrebbe prevedere un requisito di spazio libero configurabile, in modo da poterlo adattare al tuo sito.

Non so come tu stia valutando “eccessivo” — a me non sembra eccessivo.

2 Mi Piace
11

Va bene; come fai notare, ci sono molte variabili in gioco.

Beh, il “modo giusto” sarebbe calcolare la quantità di spazio necessaria per il backup, eccetera, eccetera. Ma per mantenerlo super semplice, sì, basta una percentuale fissa. Sto solo pensando… se le due opzioni sono “il tuo sito potrebbe crashare completamente e andare offline” o “ecco una soluzione non perfetta ma rapida al problema”, scelgo la seconda, grazie. :wink:

E a proposito di grazie, GRAZIE a te per tutto il tuo aiuto con la migrazione e per i tuoi pensieri su questo. :+1:t2:

1 Mi Piace
12

Stimare lo spazio necessario per il backup è uno dei problemi più difficili nell’informatica… È un lontano parente della barra di avanzamento. :wink:

Seriamente, una parte consiste in un dump del database e non so come si potrebbe stimare in anticipo. Se hai così tante immagini che lo spazio diventa un problema, includerle negli archivi di backup è probabilmente al di fuori delle pratiche comuni.

In genere, quando si parla di amministrazione di sistema, il monitoraggio dello spazio libero e lo stato dei backup sono stati un onere amministrativo piuttosto che un carico per l’applicazione. Questo fa parte di ciò per cui le persone pagano CDCK per ospitare il loro Discourse.

Ci sono molti altri modi per rimanere senza spazio. So che ti stai concentrando su quello che ti ha colpito, ma il problema è più generale e credo che questo venga normalmente affrontato come sovraccarico amministrativo.

4 Mi Piace
13

Non voglio rovinare la festa, ma in realtà, leggendo i post, non c’è una conferma solida che il processo di backup di Discourse stia causando il problema.

Perché non verificare al 100% che questo problema sia causato dal processo di backup giornaliero? Sui host sono in esecuzione più di un processo nei file crontab giornalieri.

@pnoeric ha eseguito un du sul filesystem /var/discourse (fuori dal container)?

Nei tuoi appunti, @pnoeric scrive:

root@x-app:/var/www/discourse# du -h -d 1

Ma questo comando ha completamente saltato la directory condivisa di Discourse, inclusi tutti i backup e gli upload! Inoltre, non include tutti i file Docker (e le immagini) sull’host (che possono crescere molto se le immagini non vengono pulite nel tempo).

Il posto giusto per eseguire questo controllo è fuori dal container (non dentro il container!):

Ad esempio (fuori dal container):

cd /var/discourse 
/var/discourse# du -sh *
4.0K	bin
4.0K	cids
56K	containers
12K	discourse-doctor
24K	discourse-setup
164K	image
24K	launcher
4.0K	LICENSE
12K	README.md
24K	samples
8.0K	scripts
62G	shared
148K	templates

Come potete vedere, su questo host, la directory shared è di 62G.

E anche da /var del filesystem (fuori dal container):

cd /var
# du -sh *
511M	cache
20K	composetest
62G	discourse
1.6G	docker
8.0K	legacy
52G	lib
4.0K	local
0	lock
4.0K	locks
5.7G	log
24K	logs
64K	mail
4.0K	opt
4.0K	registry
4.0K	shared
1.9M	spool
48K	tmp
25G	 linux_app
2.2G	www

Non sto cercando di rovinare la festa, ma prima di uscire e proporre un sacco di “soluzioni” per Discourse, sarebbe molto meglio confermare al 100% che il cron di backup di Discourse sia effettivamente il problema.

Non abbiamo avuto alcun problema con l’attuale processo di backup di Discourse e, inoltre, la gestione del filesystem sull’host non è un compito di Discourse in sé.

Ecco:

du

Filesystem     1K-blocks      Used Available Use% Mounted on
udev            32892500         0  32892500   0% /dev
tmpfs            6584232      2136   6582096   1% /run
/dev/md2       470927632 215969956 230966124  49% /
tmpfs           32921160         0  32921160   0% /dev/shm
tmpfs               5120         0      5120   0% /run/lock
tmpfs           32921160         0  32921160   0% /sys/fs/cgroup
/dev/md0          482922     75082    382906  17% /boot
/dev/sda1         244988      4636    240353   2% /boot/efi
tmpfs            6584232         0   6584232   0% /run/user/1000
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/0f8be368b0154285423630ad50148ee2d5fdcb357c46125eafa7374ca34ef29a/merged
shm               524288      1620    522668   1% /var/lib/docker/containers/ca7b55fc5a0c123f7b2b1234ea210aa8286a34167cba9344b7929547bd323c9b/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/7cd7e8b5b35b496eaed68753cc995e9303499a24721062055e2f06beb07e26c8/merged
shm                65536         0     65536   0% /var/lib/docker/containers/3cc0c90c3e3a5db6692e7b5d21727fbb1c13c8e07e48e4f6d954214fc03694a9/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/31533fdf68033eed96dab4f9df89025ea3dab172ed48b6ce6431840a8df1c8ea/merged
shm               524288         0    522668   0% /var/lib/docker/containers/631fbabedda9a430dd8204ec66fb45c7514d948025124171b960ea424e28d5d4/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/7a3ba2223ee93bc868b52b3707799d0fd7b4ca6dcc0df29f20c2c98a53903ff1/merged
shm                65536         0     65536   0% /var/lib/docker/containers/7a145366268c8ac5543a4555dc1bfc63c1e85a654e4c793e96fc2cc2e8514388/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/add4bdd7bd88df7a0e05dff21896d3ef796f7cf2ff9759e0bb04b1953f16cd95/merged
shm                65536         0     65536   0% /var/lib/docker/containers/123743e122089b94660a6bdd2a9e55055ad91b6f75cce4ac760f36066bcf14d0/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/b376ff32eaac0c58463e8b99b6db9ec0da3405c3f7a9f00b5430f10e07d372b0/merged
shm               524288         0    524288   0% /var/lib/docker/containers/63c52bc571b5f0d2544417da10efc37d3957e7a38f44bc8325145e795ee29559/mounts/shm

Esaminiamo i file Docker:

# cd /var/lib
# du -sh docker
30G	docker

E le nostre immagini Docker vengono regolarmente pulite e rimosse.

@bartv ha correttamente suggerito di iniziare qui:

Inizierei cercando di capire quale directory sta esplodendo. Il mio approccio standard è entrare in /var/discourse e poi eseguire du -h -d 1. Prendi la directory più grande, entra al suo interno e ripeti finché non trovi il sospetto. Una volta individuato, questo potrebbe darti un’idea di cosa stia succedendo.

Questo è un buon punto di partenza, ma ci possono essere molti altri posti sul filesystem dell’host che possono riempire il filesystem, inclusi Docker, file core, ecc.

Un grafico che mostra un picco percentuale una volta al giorno non è sufficiente per affermare con autorità che il processo cron di backup di Discourse sia la causa radice. Potrebbe esserlo, ma potrebbe non esserlo, in base alle prove finora!

6 Mi Piace
14

È fantastico. Proverò tutto ciò che hai menzionato. Grazie.

1 Mi Piace
15

Sì, è ovviamente un backup.

No, ci sono molte conferme: i picchi si verificano a intervalli di 2 giorni, con un’unica eccezione, e la frequenza dei backup è impostata su 2 giorni. Anche l’esperienza passata su Meta ha mostrato esattamente questo tipo di malfunzionamento.

Sì, questo è un piano solido per andare avanti. Tuttavia, la prima raccomandazione per chi inizia a raggiungere il limite di spazio su disco sul proprio VPS è l’archiviazione degli upload al di fuori della macchina tramite il meccanismo S3.

8 Mi Piace
16

Dato che @pnoeric sta cercando di spostarsi fuori da S3 per le immagini, conservare più copie di tutte le immagini in un backup che si trova su S3 non raggiungerebbe lo scopo di spostarsi fuori da S3. @pnoeric, questo mi crea confusione: se vuoi spostarti fuori da S3 ma sposti solo una frazione dei file perché conservi tutte le immagini su S3 in più copie di backup, qual è lo scopo?

In ogni caso, stavo cercando di mostrare come siano le alternative. Il backup è difficile, specialmente se desideri essere in grado di ripristinare dai backup.

Mi sono spostato da “S3” (nel mio caso, DigitalOcean Spaces) dopo aver avuto spazio sufficiente sul server e senza una crescita o un traffico notevoli che rendessero sensato rimanere su “S3”, ma sono un caso atipico, il che spiega probabilmente perché non ho ricevuto nemmeno una parola di revisione sulla mia PR che risolve la corruzione dei dati durante la migrazione fuori da S3. :stuck_out_tongue: Quindi mi aspetto che il mio regime di backup sia altamente atipico.

4 Mi Piace
17

La mia situazione è che ho molte immagini, il che significa un’ampia larghezza di banda per il trasferimento poiché gli utenti visualizzano queste immagini… quindi quando le immagini erano ospitate su Amazon S3, la fattura della larghezza di banda è stata davvero ciò che mi ha messo in difficoltà. Soprattutto quando ho capito che potevo archiviare tutte le immagini sul droplet di DO e che questo sarebbe stato incluso nelle spese per larghezza di banda e archiviazione che pago già. (In un momento futuro, potrebbe avere senso spostare di nuovo le cose su S3, oppure potrebbe avere più senso semplicemente aumentare di nuovo il mio droplet DO…)

Quindi ho iniziato con S3, poi ho realizzato il mio errore. Da qui la mia situazione attuale, utilizzando il tuo eccellente codice per migrare tutte le immagini da S3 di nuovo su DO.

Mantenere un backup completo (immagini e tutto il resto) su S3 è una storia completamente diversa: è in “archiviazione fredda” su S3 e non viene accessibile a meno che non si verifichi un problema. Quindi niente grandi fatture per la larghezza di banda.

Inoltre: stavo riflettendo ulteriormente sulla situazione relativa ai backup e all’utilizzo del disco. Continuo a sostenere che manca qualcosa. Forse è solo un messaggio di avviso o una documentazione migliore. Ma il mio Discourse utilizzava solo il 60% del disco, e i miei backup off-site stavano fallendo. Una sorta di stima dello spazio su disco necessario, o un avviso se non c’è spazio su disco, o qualcosa sembrerebbe essere meglio di ciò che accade ora quando non c’è abbastanza spazio, ovvero: nessun backup per diversi giorni, seguito da un crash grave che ha messo completamente offline i forum. :-\

(@riking ha persino detto che “i backup sono una fonte comune di questo tipo di fallimento.” Quindi le istanze di Discourse si bloccano regolarmente a causa di backup che falliscono senza alcun avviso di un potenziale problema?)

Per dirlo in modo molto semplice, a un livello molto alto: sembra un difetto di progettazione se una funzione di base del software (backup automatici) può mettere offline l’intero sistema. Soprattutto quando si parla di una funzione che utilizza solo spazio su disco per preparare il backup, senza nemmeno archiviarlo sullo stesso disco.

1 Mi Piace
18

No, intendeva dire che eseguire backup tramite qualsiasi software su qualsiasi server può potenzialmente riempire il disco e causare problemi.

3 Mi Piace
19

Certo, ma è per questo che si mette un CDN davanti a S3. Non servire le immagini direttamente da S3, sarebbe costosissimo :scream:. Puoi mettere Cloudfront o persino CloudFlare davanti a S3 con relativa facilità. Il piano gratuito di CloudFlare è sufficiente per farlo.

Inoltre, archiviarle localmente è una pessima idea: dovresti scalare il tuo VPS inutilmente. Gli SSD locali sono molto più costosi.

7 Mi Piace
20

Ah, ok, ho capito.

Quindi come posso sapere quanto spazio su disco potrebbe essere necessario a Discourse per preparare un backup? Il software non me lo dice, quindi magari domani sarà di 500 GB e porterà di nuovo offline il mio server Digital Ocean. :man_shrugging:t2: Almeno, se riesco a fare qualche calcolo approssimativo, posso cercare di tenermi aggiornata/o.

Wow, che ottima idea. Non ci avevo mai pensato. Quindi dovrei applicare la CDN al mio bucket Amazon e poi dire a Discourse di usare S3 per tutte le risorse? (Come facevo prima? lol)

3 Mi Piace