Salut à tous, j’espère avoir de l’aide !
Quelqu’un a-t-il déjà rencontré ce problème ?
./launcher rebuild app est en cours d’exécution, il arrive à ce point et reste bloqué ici.
Maintenant, il fait quelque chose, mais il le fait extrêmement lentement. J’utilise le forum via une instance Digital Ocean auto-installée depuis 3 ans, mais c’est nouveau et cela cause beaucoup d’interruptions. Y a-t-il un moyen d’accélérer cela ? Est-ce lié aux images sur le forum ou à autre chose ?
Pouvez-vous ouvrir une autre session SSH et essayer de trouver quelle migration pose problème ?
Quelque chose comme ps aux | grep postgres devrait montrer le début.
Je ne suis pas un expert en Linux (ou, franchement, même un amateur) mais je vais essayer.
Je suppose que la mémoire est pleine. Vous pouvez essayer
free -h
Peut-être aussi
du -hs /var/discourse/shared/standalone/*
Mémoire (RAM) ou espace disque ?
Je pense qu’il devrait y en avoir beaucoup des deux - Le Droplet est : 8 Go de mémoire / 4 vCPU Intel / 160 Go de disque + 200 Go / Ubuntu 18.04.3 (LTS) x64
Est-il « sûr » d’ouvrir une autre session SSH et de les exécuter pendant que ce db:migrate est toujours en cours ?
Si j’étais vous, je commencerais par obtenir un nouveau VPS avec un système d’exploitation qui bénéficie encore d’un support actif.
Oui.
D’accord - s’il vous plaît, comprenez que je ne suis PAS un expert en Linux - votre message sous-entend que la version actuelle d’Ubuntu est très obsolète, etc. ?
Oui, le système d’exploitation date d’avril 2018 et a été pris en charge pendant 5 ans, donc cela s’est terminé il y a plus de 6 mois.
J’apprécie l’information.
En tant que personne qui admet volontiers être un amateur faisant de son mieux, avez-vous des recommandations sur ce que je devrais faire ensuite ?
La migration de la base de données a échoué - le message était :
client_loop: send disconnect: Connection reset
En me reconnectant, vous avez tout à fait raison :
Nouvelle version ‘20.04.6 LTS’ disponible.
Exécutez ‘do-release-upgrade’ pour la mettre à niveau.
Compte tenu que mon forum est actuellement hors service, puis-je effectuer la mise à niveau en toute sécurité, puis m’occuper de réparer le forum ? ou devrais-je d’abord essayer de le remettre en ligne ?
C’est une erreur SSH…
Avez-vous effectué une sauvegarde avant la mise à niveau ? Si oui, le plus simple serait d’obtenir un nouveau serveur avec Ubuntu 22, d’installer Discourse et de restaurer la sauvegarde.
Hélas, un de mes administrateurs a appuyé sur le bouton de mise à niveau du site, et il semble que cela ait échoué puis tout cassé. 
La dernière sauvegarde a été effectuée hier - donc ce n’est pas trop grave.
Je suppose qu’une mise à niveau du serveur existant effacerait l’installation existante ?
(Merci pour votre patience @RGJ d’ailleurs)
Difficile à dire, mais comme les choses échouent, je ne prendrais pas de risque. Du moins pas avant de m’assurer que la sauvegarde est stockée dans un endroit sûr.
Il y a de fortes chances que vous puissiez démarrer une nouvelle VM, arrêter le conteneur (il semble qu’il ne tourne pas de toute façon), puis synchroniser (rsync) le tout vers le nouveau serveur et réessayer là-bas. Cela pourrait probablement vous permettre de redémarrer sans perdre de données.
Tout cela semble si simple, mais bon sang, je me sens dépassé ici. Il tourne actuellement sur une gouttelette DigitalOcean. Donc, démarrer une nouvelle VM - c’est une phrase chargée ? Sur la même gouttelette ? Sur une nouvelle ? 
Une VM est le terme courant pour ce que DigitalOcean appelle une gouttelette.
On dirait que vous voudriez peut-être jeter un œil à mon profil et envisager l’hébergement géré 
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 montre que discourse [local] delete est ce qui consomme 100% du CPU. Le droplet a 8 Go de RAM, et actuellement moins de 1 Go est utilisé (sans compter les buffers).
L’OS est obsolète, mais cela me semble très étrange. Il y a beaucoup de RAM et de disque, et cette tâche de suppression postgres s’exécute depuis plus de 12 minutes. Il y a moins de 600K posts et moins de 4K utilisateurs, donc la base de données n’est pas énorme. Oh. Attendez. Le répertoire postgres_data fait 28 Go.
J’ai exécuté un VACUUM VERBOSE ANALYZE;.
J’ai fait ceci :
discourse=# SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter;
checkpoints_timed | checkpoints_req
-------------------+-----------------
6 | 20
J’essaie maintenant de réindexer en mode concurrent. Peut-être que le vacuum et le réindex aideront.
Merci Jay. Fais-moi savoir si tu as besoin de quoi que ce soit de ma part.
Veuillez partager tout le SQL de la requête longue durée.
Où est-ce que je trouve ça ?
La migration n’imprime aucun journal. La dernière ligne dans la reconstruction est
I, [2023-12-04T22:33:33.759401 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
Je travaille sur un journal complet pour celui que je viens de redémarrer.
Entrez dans le conteneur, basculez vers l’utilisateur postgres, entrez psql et exécutez
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;