Non è un mio problema, ma questo significa che non c’è nient’altro?
1 Mi Piace
Forse non intenzionalmente, ma potrebbe valere la pena controllare il contenuto dell’host per processi di mining di criptovalute, ecc…
3 Mi Piace
Passaggio 1: correggere il problema di prestazioni già identificato relativo all’utilizzo del driver vfs
7 Mi Piace
Riguardo a questo passaggio a (idealmente) overlay2, dovrò cancellare la mia attuale installazione e reinstallare tutto. Questo perché l’host su cui mi trovo attualmente supporta solo fuse-overlayfs o vfs, nessuno dei quali è raccomandato.
Tuttavia, a breve abiliteranno i KVM che supportano overlay2.
Quindi la mia intenzione sarebbe quella di utilizzare quello, invece dell’altrettanto non suggerito fuse-overlayfs.
Ora, nell’app Discourse stessa, posso fare dei backup. Cosa salvano precisamente?
Perderei qualcosa dall’attuale forum Discourse (intendo messaggi, chat, impostazioni, utenti, immagini caricate, ecc.) se facessi un backup, reinstallassi un Discourse nuovo su un server nuovo, e poi dopo la configurazione iniziale di Discourse, lo sovrascrivessi con il backup?
Funzionerebbe?
Sì, funzionerebbe.
L’unica cosa che non hai menzionato è assicurarsi di avere gli stessi plugin sul nuovo Discourse di quelli attuali. Se riutilizzi il tuo app.yml andrebbe bene lo stesso.
3 Mi Piace
Va bene, grazie per avermelo fatto notare, scommetto che ci sarei incappato.
Ok, allora…
- Esegui il backup nell’area di amministrazione di Discourse
- Solo per sicurezza, ovviamente, esegui il backup del server
- Prendi una copia del file yaml
- Scarica il server
- Imposta un nuovo server con tecnologia supportata
- Installa Docker con il driver di archiviazione appropriato
- Ricostruisci un’istanza Discourse completamente nuova utilizzando il file yaml di backup
- Ripristina Discourse dal backup
Sorpreso che il backup sia solo di 19,2 MB.
Abbiamo già caricato diverse immagini, ecc… ma immagino che tutto ciò che posso fare è provare.
Ci proverò nel fine settimana e ti farò sapere se la modifica del driver di archiviazione ha funzionato.
1 Mi Piace
Verifica che sia impostato questo:
1 Mi Piace
Si prega di notare che questa specifica impostazione si applica solo ai backup pianificati, non a quelli manuali. Con i backup manuali si ottiene sempre una scelta esplicita.
Un’altra impostazione da abilitare è include thumbnails in backups (includi miniature nei backup)
@smileBeda Rimanderei il #4 finché tutto non funzionerà correttamente.
3 Mi Piace
È effettivamente selezionato, ma Includi miniature generate nei backup. La disattivazione renderà i backup più piccoli, ma richiederà una nuova elaborazione di tutti i post dopo un ripristino. non lo era.
@RGJ … giusto, buona idea, richiederà più passaggi poiché dovrò creare un server sotto una nuova entità, ma è minimo rispetto al rischio.
Lascerò che il backup automatico si attivi in modo da ottenere tutti i dati al suo interno, poiché ho capito che quello manuale non includerebbe immagini, ecc.
Grazie…
Questa è un’ipotesi errata.
Quando si crea un backup manualmente, si ottiene la scelta in un popup se si desidera eseguire il backup solo del database o includere i caricamenti.
Quando si creano backup pianificati, l’impostazione backup with uploads decide questo.
4 Mi Piace
Ok, ho frainteso il tuo precedente Si prega di notare che tale impostazione specifica si applica solo ai backup pianificati, non a quelli manuali.
Grazie…
2 Mi Piace
Ciao, riapro questo argomento dato che è ancora aperto e stiamo riscontrando lo stesso problema dopo la migrazione a un nuovo server virtuale. Come dicono tutti, non ci ho mai messo più di 20 minuti per ricostruire il nostro Discourse, ma su questo nuovo server ci vogliono ore, e ha il doppio delle risorse del precedente. 
Ho controllato altri argomenti relativi a upgrade che durano ore su Meta, ma non riesco a capire quale sia il problema con il nostro:
Server: 4Gb RAM, 2CPU, 50 Gb disco.
Swap:
/$ free
total used free shared buff/cache available
Mem: 3911740 507208 2318476 268 1384032 3404532
Swap: 4095976 45472 4050504
Docker:
/$ sudo docker info
Client:
Version: 26.1.3
Context: default
Debug Mode: false
Server:
Containers: 3
Running: 0
Paused: 0
Stopped: 3
Images: 3
Server Version: 26.1.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version:
runc version:
init version:
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.8.0-31-generic
Operating System: Ubuntu 24.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.731GiB
Name: podkasts
ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Mi sembra normale, ma forse mi sfugge qualcosa. Dove altro possiamo guardare?
Forse un vicino rumoroso sta rendendo la tua nuova VM più lenta di quella vecchia perché sta usando tutta la CPU che non stai ottenendo?
1 Mi Piace
Sì, grazie, è rassicurante che un amministratore esperto come te non veda nulla di ovvio nelle informazioni di cui sopra. E sì, stiamo iniziando a esaminare il server fisico e il nostro vicinato virtuale. Almeno il forum funziona senza problemi evidenti per gli utenti. Stiamo riscontrando questo grave problema di prestazioni solo con le ricostruzioni. Ieri ci sono volute 4 ore per ricostruire. 
1 Mi Piace
Se avessi questo problema, avrei due o tre finestre del terminale aperte. Una per eseguire la ricostruzione, una per prendere appunti sul tempo trascorso e per annotare dove si verificano i lunghi ritardi tra gli aggiornamenti dei log, e l’ultima per tenere un registro dell’attività della macchina: probabilmente eseguendo vmstat 5
Quando raggiungi un punto in cui il log non si aggiorna per un tempo sospettosamente lungo, prendi nota dell’attività segnalata da vmstat.
Pubblica qui estratti adatti dal log con i tuoi appunti e l’output vmstat corrispondente.
Sembra molto probabile che siano parti specifiche della ricostruzione a richiedere tempo: la cosa da fare è scoprire quali parti e vedere cosa sta facendo la macchina in quei momenti.
Probabilmente farei anche uno snapshot dell’attività della macchina con ps auxf durante le pause.
4 Mi Piace
Grazie, questo è un ottimo consiglio. La prossima volta che dovremo ricostruire, lo faremo in questo modo.
2 Mi Piace