Olá a todos, espero ajuda!
Alguém já passou por isso antes?
./launcher rebuild app está em execução, chega a este ponto e fica travado aqui.
Agora está fazendo algo, mas está fazendo isso extremamente devagar. Tenho executado o fórum em uma instância autoinstalada da DigitalOcean há 3 anos, mas isso é novo e está causando muita inatividade. Existe uma maneira de suavizar isso? Tem a ver com imagens no fórum ou algo assim?
Você pode abrir outra sessão SSH e tentar encontrar qual migração está causando problemas?
Algo como ps aux | grep postgres deve mostrar o início dela.
Não sou um especialista em Linux (ou, francamente, nem mesmo um amador), mas vou tentar.
Minha suspeita é que está acabando a memória. Você pode tentar
free -h
Talvez também
du -hs /var/discourse/shared/standalone/*
Memória (RAM) ou Espaço em Disco?
Deveria haver bastante de ambos, eu penso - o Droplet é: 8 GB de Memória / 4 vCPUs Intel / 160 GB de Disco + 200 GB / Ubuntu 18.04.3 (LTS) x64
É “seguro” abrir outra sessão SSH e executá-las enquanto este db:migrate ainda está em execução?
Se eu fosse você, começaria por obter um novo VPS com um sistema operacional que ainda tivesse suporte ativo.
Sim.
Ok - por favor, entenda que NÃO sou um especialista em Linux - sua postagem sugere que a compilação atual do Ubuntu está muito desatualizada, etc.?
Sim, o sistema operacional é de abril de 2018 e foi suportado por 5 anos, então isso terminou há mais de 6 meses.
Agradeço a informação.
Como alguém que admite livremente ser um amador fazendo o seu melhor - alguma recomendação sobre o que devo fazer a seguir?
O db:migrate falhou - a mensagem foi:
client_loop: send disconnect: Connection reset
Ao fazer login novamente, você está absolutamente certo:
Nova versão ‘20.04.6 LTS’ disponível.
Execute ‘do-release-upgrade’ para atualizar para ela.
Considerando que meu fórum está atualmente fora do ar, posso fazer o upgrade com segurança e depois me preocupar em consertar o fórum? ou devo tentar colocá-lo online primeiro?
Esse é um erro de SSH…
Você fez um backup antes de atualizar? Se sim, o mais fácil seria obter um servidor novo com Ubuntu 22, instalar o Discourse e restaurar o backup.
Puxa, um dos meus administradores apertou o botão de upgrade no site, e parece que falhou e quebrou tudo. 
O último backup foi feito ontem - então não está tão ruim.
Eu entendo que um upgrade para o servidor existente apagaria a instalação existente?
(Obrigado pela sua paciência @RGJ, aliás)
Difícil dizer, mas como as coisas estão falhando, eu não arriscaria. Pelo menos não antes de ter certeza de que o backup está armazenado em um local seguro.
Há uma chance razoável de você poder iniciar uma nova VM, parar o contêiner (parece que ele não está em execução de qualquer maneira) e, em seguida, usar rsync para transferir tudo para o novo servidor e tentar novamente lá. Isso provavelmente pode fazer você voltar a funcionar sem perder nenhum dado.
Tudo parece tão simples, mas nossa, estou me sentindo fora da minha profundidade aqui. Atualmente está rodando em um droplet da DigitalOcean. Então, iniciar uma nova VM - essa é uma frase carregada? No mesmo droplet? Em um novo? 
Uma VM é o termo comum para o que a DigitalOcean chama de droplet.
Parece que você pode querer dar uma olhada no meu perfil e considerar hospedagem gerenciada 
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
O htop mostra que o discourse [local] delete é o que está consumindo 100% da CPU. O droplet tem 8GB de RAM, e no momento <1GB está em uso (sem contar buffers).
O SO está desatualizado, mas isso me parece muito estranho. Há RAM e disco de sobra, e essa tarefa de delete do postgres está rodando há mais de 12 minutos. Há menos de 600K posts e <4K usuários, então o banco de dados não é enorme. Ah. Espere. O diretório postgres_data tem 28GB.
Executei um VACUUM VERBOSE ANALYZE;.
Eu fiz isso:
discourse=# SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter;
checkpoints_timed | checkpoints_req
-------------------+-----------------
6 | 20
Estou agora tentando reindexar concorrentemente. Talvez o vacuum e o reindex ajudem.
Obrigado, Jay. Me avise se precisar de algo de mim.
Por favor, compartilhe todo o SQL da consulta de longa duração.
Onde encontro isso?
A migração não está imprimindo nenhum log. A última linha na reconstrução é
I, [2023-12-04T22:33:33.759401 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
Estou trabalhando em um log completo para o que acabei de reiniciar.
Entre no contêiner, mude para o usuário postgres, entre no psql e execute
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;