Ciao a tutti, spero in un aiuto!
Qualcuno ha già riscontrato questo problema?
./launcher rebuild app è in esecuzione, arriva a questo punto e rimane bloccato qui.
Ora sta facendo qualcosa, ma lo sta facendo estremamente lentamente. Gestisco il forum tramite una droplet Digital Ocean auto-installata da 3 anni, ma questa è una novità e sta causando molti tempi di inattività. C’è un modo per risolvere questo problema? È legato alle immagini sul forum o a qualcos’altro?
Puoi aprire un’altra sessione SSH e provare a trovare quale migrazione sta causando problemi?
Qualcosa come ps aux | grep postgres dovrebbe mostrarne l’inizio.
Non sono un esperto di Linux (o, francamente, nemmeno un dilettante) ma ci proverò.
A mia supposizione è che si stia esaurendo la memoria. Puoi provare
free -h
Forse anche
du -hs /var/discourse/shared/standalone/*
Memoria (RAM) o Spazio su disco?
Penso che ce ne dovrebbe essere in abbondanza di entrambi - il Droplet è: 8 GB di memoria / 4 vCPU Intel / 160 GB di disco + 200 GB / Ubuntu 18.04.3 (LTS) x64
È “sicuro” aprire un’altra sessione SSH ed eseguirli mentre questo db:migrate è ancora in esecuzione?
Se fossi in te, inizierei procurandomi un nuovo VPS con un sistema operativo che abbia ancora supporto attivo.
Sì.
Va bene, ti prego di capire che NON sono un esperto di Linux: il tuo post suggerisce che la versione attuale di Ubuntu sia super obsoleta, ecc.?
Sì, il sistema operativo risale all’aprile 2018 ed è stato supportato per 5 anni, quindi è terminato oltre 6 mesi fa.
Apprezzo le informazioni.
Come qualcuno che ammette liberamente di essere un dilettante che fa del suo meglio, hai qualche raccomandazione su cosa dovrei fare dopo?
Il db:migrate è fallito - il messaggio era:
client_loop: send disconnect: Connection reset
Accedendo di nuovo, hai perfettamente ragione:
Nuova release ‘20.04.6 LTS’ disponibile.
Esegui ‘do-release-upgrade’ per aggiornare.
Considerando che il mio forum è attualmente inattivo, posso procedere tranquillamente con l’aggiornamento e poi preoccuparmi di sistemare il forum? o dovrei prima cercare di rimetterlo online?
Quello è un errore SSH…
Hai fatto un backup prima dell’aggiornamento? Se sì, sarebbe più facile ottenere un server nuovo di zecca con Ubuntu 22, installare Discourse e ripristinare il backup.
Ahimè, uno dei miei amministratori ha premuto il pulsante di aggiornamento sul sito, e sembra che sia fallito e abbia poi rotto tutto. 
L’ultimo backup è stato effettuato ieri, quindi non è troppo grave.
Mi pare di capire che un aggiornamento al server esistente cancellerebbe l’installazione esistente, giusto?
(Grazie per la tua pazienza @RGJ comunque)
Difficile da dire, ma dato che le cose stanno fallendo, non correrei il rischio. Almeno non prima di essermi assicurato che il backup sia conservato in un luogo sicuro.
C’è una discreta possibilità che tu possa avviare una nuova VM, arrestare il container (sembra che non sia in esecuzione comunque) quindi usare rsync per trasferire tutto sul nuovo server e riprovare lì. Questo probabilmente ti permetterà di tornare operativo senza perdere dati.
Sembra tutto così semplice, ma cavolo, mi sento fuori dalla mia portata qui. Attualmente è in esecuzione su una droplet di DigitalOcean. Quindi avviare una nuova VM - è una frase carica? Sulla stessa droplet? Su una nuova? 
Una VM è il termine comune per quello che DigitalOcean chiama droplet.
Sembra che tu voglia dare un’occhiata al mio profilo e considerare l’hosting gestito 
ystemd+ 7660 0.0 0.3 352060 28284 ? S 22:31 0:00 /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
systemd+ 7667 0.0 0.1 352588 9628 ? Ss 22:31 0:00 postgres: 13/main: checkpointer
systemd+ 7668 0.3 0.9 352060 78796 ? Ss 22:31 0:03 postgres: 13/main: background writer
systemd+ 7669 0.0 0.1 352060 13696 ? Ss 22:31 0:00 postgres: 13/main: walwriter
systemd+ 7670 0.0 0.1 352728 11892 ? Ss 22:31 0:00 postgres: 13/main: autovacuum launcher
systemd+ 7671 0.0 0.0 67996 5320 ? Ss 22:31 0:00 postgres: 13/main: stats collector
systemd+ 7672 0.0 0.0 352612 6640 ? Ss 22:31 0:00 postgres: 13/main: logical replication launcher
systemd+ 10900 82.0 3.8 487164 317728 ? Rs 22:33 10:42 postgres: 13/main: discourse discourse [local] DELETE
systemd+ 10901 0.0 0.1 353432 13804 ? Ss 22:33 0:00 postgres: 13/main: discourse discourse [local] idle
htop mostra che il discourse [local] delete sta consumando il 100% della CPU. Il droplet ha 8GB di RAM e al momento viene utilizzata meno di 1GB (senza contare i buffer).
Il sistema operativo è obsoleto, ma questo mi sembra molto strano. C’è molta RAM e disco, e quel task di delete di postgres è in esecuzione da oltre 12 minuti. Ci sono meno di 600K post e meno di 4K utenti, quindi il database non è enorme. Oh. Aspetta. la directory postgres_data è di 28GB.
Ho eseguito un VACUUM VERBOSE ANALYZE;.
Ho fatto questo:
discourse=# SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter;
checkpoints_timed | checkpoints_req
-------------------+-----------------
6 | 20
Sto ora provando a fare un reindex concorrente. Forse il vacuum e il reindex aiuteranno.
Grazie Jay. Fammi sapere se hai bisogno di qualcosa da parte mia.
Per favore, condividi l’intero SQL della query in esecuzione da molto tempo.
Dove lo trovo?
La migrazione non sta stampando alcun log. L’ultima riga nella ricostruzione è
I, [2023-12-04T22:33:33.759401 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
Sto lavorando a un log completo per quello che ho appena riavviato.
Entra nel container, passa all’utente postgres, entra in psql ed esegui
SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;