ディスク容量の問題に加えて、アップグレード処理が Droplet に割り当てられた利用可能なメモリ（1GB）を超えてしまった可能性はないでしょうか？上記のコンソールスクリーンショットを見ると、./launcher rebuild app の実行後に最初に記録されたログに「Out of memory」という記述があります。
前述していませんでしたが、その試みの後、コンソールが応答しなくなりました（当時は DigitalOcean のコントロールパネル内の Web ベースのコンソールを使用しており、これは常に不安定です）。その後、Droplet を再起動しました（それ以降は PuTTY を使用しました）。
いずれにせよ、Discourse のアップグレードページで更新が成功したと報告されたにもかかわらず、おそらく同じメモリおよび/またはディスクの問題に直面していたのであれば、これは決して良い状況ではありません。
ああ、OOM キラーが作動しましたね。それは確かに好ましくありません。通常はスワップ領域を増やすことをお勧めします。swapon で現在の使用状況を確認できます。私の場合は以下の通りです。
# swapon
NAME TYPE SIZE USED PRIO
/swapfile file 2G 3M -2
また、free コマンドも確認できます。
# free
total used free shared buff/cache available
Mem: 1992060 792904 80148 34696 1119008 1004956
Swap: 2097148 3084 2094064
2G のスワップファイルが機能していないのは問題です。また、ディスク領域を使わずにスワップを追加できないのも問題です。
アップグレードのためのディスク領域を確保する一つの方法は、すべてのバックアップファイルをオフサイトにコピーし、整合性を確認してからサーバーから削除することです。アップグレード中は、万が一に備えて安全な場所に最近のバックアップが必ず必要ですが、それがサーバー自体にある必要はありません。最新のもの以外を削除しても安心ですが、オフラインコピーは必ず取っておくことをお勧めします。
すべてのクリーンアップを行った後、du の結果を再度確認すると良いでしょう。
気になります：1GはRAM割り当てで、25Gはディスク割り当てということでしょうか？これらは全く異なるものです。
編集：サポートされている標準的な話としては、1Gよりもかなり多くのRAMを持つことが望ましいと思います。
編集：いいえ、どうやら 1Gがまだ推奨される絶対最小値のようです。
再度接続しました。コンソールウィンドウの起動時に報告されたシステム情報は以下の通りです。
システム負荷：0.01 プロセス数：136
/の使用状況：24.06GB の 59.4% ログイン中のユーザー：0
メモリ使用率：73% eth0 の IP アドレス：159.65.140.176
スワップ使用率：17% docker0 の IP アドレス：172.17.0.1
つまり、スワップ領域の使用率が 17% ということは 4GB に相当するのでしょうか？
フォーラムにログインしているユーザーが誰もおらず、現在アクティブなのは droplet への PuTTY 接続のみなのに、RAM は 73% 使用されています。つまり、わずかなアクティビティでもフォーラムがスワップ領域に追い込まれてしまう可能性があります。さらに、それが 24GB のディスク領域から消費される場合、ディスク使用量がすでに高い状態で更新を行うと、まさに「完璧な嵐」が起きるかもしれません。
du -kx / | sort -n | tail -33 を実行すると、以下の結果が得られます。
root@nz:~# du -kx / | sort -n | tail -33
505512 /usr/bin
528784 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor/bundle/ruby/2.6.0
528788 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor/bundle/ruby
528792 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor/bundle
536848 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor
548952 /var/lib/docker/overlay2/c126267f944d8d7f12415ac4f5908eba8a6a686b093cad3e0115eded8edfd6ba/diff
548968 /var/lib/docker/overlay2/c126267f944d8d7f12415ac4f5908eba8a6a686b093cad3e0115eded8edfd6ba
817700 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/usr/lib
827812 /var/log/journal/8bebc832e1a692c83690ffe65e1256e3
868792 /var/log/journal
1069356 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse
1069368 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www
1069396 /var/log
1142352 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var
1202004 /var/discourse/shared/standalone/import/data
1307816 /var/discourse/shared/standalone/import
1362804 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/usr
1399332 /var/discourse/shared/standalone/backups/default
1399336 /var/discourse/shared/standalone/backups
1709408 /usr
2438224 /var/discourse/shared/standalone/postgres_data/base/16583
2462944 /var/discourse/shared/standalone/postgres_data/base
2481288 /var/discourse/shared/standalone/postgres_data
2540188 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff
2540204 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35
3387776 /var/lib/docker/overlay2
3460136 /var/lib/docker
3830584 /var/lib
5629420 /var/discourse/shared/standalone
5629504 /var/discourse/shared
5632224 /var/discourse
10747244 /var
14961492 /
root@nz:~#
これについては、journalctl を使って改善できるかもしれません。例えば、
# journalctl --vacuum-size=50M
（アップグレードを試みる直前に実行すると良いでしょう）
PostgreSQL の使用量が減っていないのは興味深いですね。
free コマンドでスワップの使用状況を確認できます。現在 17% 使用されており、その量は恐らく 2GB 程度です。
あなたのマシンは明らかに容量が少し不足しています。RAM を増やすか、スワップ領域を増やす必要があります。ディスク容量を増やさない限り、スワップを大幅に増やすことは現実的ではありません。
お詫び申し上げます。ご指摘の通りです。1GB はディスク使用量ではなく、RAM の割り当てでした。
またもやその通りですね。
root@nz:~# free
total used free shared buff/cache available
Mem: 1008828 655660 61716 102288 291452 96576
Swap: 2097148 459776 1637372
アップグレード処理が開始される直前に、ホストシステムの容量を評価してアップグレードの実施可否を確認すべきではないでしょうか？
未来を予知することと同じような話だと思います！5GB のディスク容量のチェックは明らかに役立ちますが、完全に確実なものではありません。空き RAM はより難しく、どれくらい必要になるかは非常に流動的です。それは、フォーラムがどれほど大きくなったか、そして各アップグレード時に何を変更する必要があるかによって決まると考えられます。
私はコストを最小限に抑えるよう注意しているので、安価なサーバーに収まるように時間をかけて調整します。しかし、最終的にはフォーラムが成長するにつれ、次のティアへ移行する価値が必ず出てきます。それにはお金がかかりますが、時間と労力を節約できます。
残念ながら、私はコスト最小化の側にあります。このフォーラムは完全にボランティアによる活動で収益を生んでおらず、ユーザーから要求されたメール投稿機能（MailGun を経由）の追加により、現在でも運営維持に毎月いくらかのコストがかかります。
趣味の範囲で考えれば、ナイトクラブで飲むよりも安いと思いますよ！
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.