皆さん、こんにちは。ご協力をお願いします！
どなたか以前にこのような経験をされた方はいらっしゃいますか？
./launcher rebuild app を実行すると、この地点まで到達し、そこでハングしてしまいます。
今、何か処理はしていますが、非常に遅いです。3年間、セルフインストールしたDigitalOceanドロップレットでフォーラムを運営してきましたが、これは初めてのことで、多くのダウンタイムを引き起こしています。これをスムーズにする方法はありますか？フォーラムの画像に関連しているのでしょうか？
別のSSHセッションを開いて、どのマイグレーションが問題を引き起こしているか見つけられますか？
ps aux | grep postgres のようなコマンドで開始部分を確認できるはずです。
私はLinuxの専門家ではありません（率直に言って、アマチュアでもありません）が、やってみます。
メモリ不足が原因だと思われます。以下のコマンドを試してみてください。
free -h
また、以下のコマンドも試してみてください。
du -hs /var/discourse/shared/standalone/*
メモリ（RAM）かディスク容量か？
どちらも十分にあるはずだと思います。Dropletは次のとおりです。8 GB メモリ / 4 Intel vCPU / 160 GB ディスク + 200 GB / Ubuntu 18.04.3 (LTS) x64
このdb:migrateがまだ実行中に、別のSSHセッションを開いてそれらを実行しても「安全」ですか？
もし私なら、まだサポートがアクティブなOSを搭載した新しいVPSを取得することから始めます。
はい。
わかりました。私はLinuxの専門家ではないことをご理解ください。あなたの投稿は、現在のUbuntuのビルドが非常に古いことを示唆していますか？
はい、OSは2018年4月のもので、5年間サポートされていましたので、6か月以上前に終了しています。
情報ありがとうございます。
自分のベストを尽くしているアマチュアであることを率直に認める者として、次に何をすべきか、何かお勧めのことはありますか？
db:migrate は失敗しました。メッセージは次のとおりです。
client_loop: send disconnect: Connection reset
再度ログインすると、おっしゃる通りです。
新しいリリース「20.04.6 LTS」が利用可能です。
「do-release-upgrade」を実行してアップグレードしてください。
現在フォーラムがダウンしていることを考慮すると、フォーラムの修正に取り組む前に、アップグレードを実行しても安全でしょうか？それとも、まずフォーラムをオンラインに戻そうとすべきでしょうか？
それはSSHエラーですね…
アップグレード前にバックアップを取りましたか？もし取っていれば、Ubuntu 22で新しいサーバーをセットアップし、Discourseをインストールしてバックアップを復元するのが最も簡単でしょう。
残念ながら、管理者の1人がサイトのアップグレードボタンを押してしまい、それが失敗してすべてが壊れてしまったようです。
最後のバックアップは昨日取られたものなので、それほど悪くはありません。
既存のサーバーへのアップグレードは、既存のインストールをすべて消去してしまうということでしょうか？
（@RGJさん、忍耐強く対応していただきありがとうございます。）
判断が難しいですが、問題が発生しているため、試すのは避けた方が良いでしょう。少なくとも、バックアップが安全な場所に保存されていることを確認する前には。
新しい仮想マシンを起動し、コンテナを停止して（いずれにせよ実行されていないようです）、それからすべてを新しいサーバーに rsync して、そこで再度試すという十分な可能性があります。これにより、データを失うことなく、おそらく復旧できるでしょう。
すべてがとてもシンプルに聞こえますが、私はここで自分の能力を超えていると感じています。現在、DigitalOceanのドロップレットで実行されています。新しいVMを起動するというのは、意味深な言葉ですか？同じドロップレットに？新しいドロップレットに？
VM は、DigitalOcean が Droplet と呼ぶものの一般的な用語です。
私のプロフィールをご覧になり、マネージドホスティングをご検討いただくのが良いかもしれません 
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 によると、CPU を 100% 消費しているのは discourse [local] delete です。ドロップレットは 8GB の RAM を搭載しており、現在使用されているのは 1GB 未満です（バッファは除く）。
OS は最新ではありませんが、これは非常に奇妙に思えます。RAM もディスクも十分あり、その postgres delete タスクは 12 分以上実行されています。投稿は 60 万未満、ユーザーは 4 千未満なので、データベースはそれほど大きくありません。ああ、待ってください。postgres_data ディレクトリは 28GB です。
VACUUM VERBOSE ANALYZE; を実行しました。
これを実行しました：
discourse=# SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter;
checkpoints_timed | checkpoints_req
-------------------+-----------------
6 | 20
現在、同時にインデックスを再構築しようとしています。バキュームとインデックスの再構築が役立つかもしれません。
ジェイさん、ありがとうございます。何か私にできることがあれば教えてください。
長時間実行されているクエリの SQL 全体を共有してください。
それはどこで見つけられますか？
マイグレーションでログが出力されていません。リビルドの最後の行は次のとおりです。
I, [2023-12-04T22:33:33.759401 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
再起動したばかりのものの完全なログを作成しています。
コンテナに入り、postgresユーザーに切り替えて、psqlを実行し、以下を実行します。
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;