わかりました、理解できます。ブートストラップ/コンパイルプロセスを、制約されたリソース(つまりRAM)内で、より長く(CPU/シリアライズ)実行するように合理化することはできないでしょうか?
それは素晴らしいアイデアだと思います。そしてその理由の一つはこれです。もし小さなサーバーで再構築できないなら、小さなサーバーにインストールすることもできません。そして、中規模のサーバーにインストールした場合、小さなサーバーで必要となるスワップファイルが作成されません。(理想的には、インストールスクリプトがスワップファイルを作成し、設定すべき2つのカーネルチューナブルも設定するでしょう。)
これも素晴らしいアイデアです。理想的には、ソフトウェアエンジニアリングプロセスがビルド時間を監視するように、そうしないとビルド時間がどんどん長くなるため、Discourseの場合は、プロセスが理想的には小さなインスタンスでのインストール可能性をテストおよび監視することになります。それを目標にしてください。
起動時にアセットを移行および事前コンパイルするブートストラップ済みイメージを実験しました(これらのタスクをスキップするためのENV設定付き)。これはほとんどの場合機能します(巨大なサイトや、特定の時間内に起動が発生することを期待するものには、それほど機能しません)。
ただし、これらはRedisとPostgresが存在することを前提としています。
ほとんど標準的な2コンテナインストールで、ほとんどの場合機能させることができるかもしれません。
おーーーーーーーーーーーーーーーーーーーー、しかし、事前コンパイルアセットが問題を引き起こしているステップだと思います。
Ember 5 のアップグレードがシステム全体で進行中であることについて読んでいます。ビルドリソースへの影響はどのようなものになりますか?
ドキュメントの更新が必要だと思います。discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub
- 1 GB RAM のデフォルトは、小規模な Discourse コミュニティでは問題なく動作します。
1GB はもはや選択肢ではありません。Discourse をビルドするための最小要件は 2GB です。
最近1GBのRAMにアップグレードしたサイトがいくつかあります。ただし、スワップは3GBまたは4GBに増やしました。
お勧めはしませんが、コストの壁が高く、なんとかやっている人もいます。しかし、「問題なく動作する」というのは誇張かもしれません。
はい、おそらくそれを指定してください。RAM 1GB + スワップ 4GB。スワップ 2GB では失敗しました。
プラグインはありますか?テーマはたくさんありますか?
9つのプラグインと1つのテーマのみ。これもすべて3.1.xまでは正常に動作していました。1GBのRAMと2GBのスワップ(少し遅く、再構築に20分ほどかかりましたが、常に機能していました)で動作していました。
3.2.0にアップグレードしようとすると、一貫して失敗しました(上記参照)。
はい。1GBのRAMでプラグインが動作しないのは確かです。これはインストール手順に追加すべきことのようです。
プラグインなしで動作したかどうか、知りたいです。
極端な短縮形として、あなたがそう言う理由は理解できますが、Discourseを実行するための「ゴー/ノーゴー」はRAM+スワップではないでしょうか? 1+3はゴー/ノーゴーの観点からは2+2と同じです。
RAMの量に関係するのはパフォーマンス(応答性)だけです。
RAM+スワップをチェックしてテストするのが正しい方法です。メモリ=RAM+スワップ。
ちなみに、明白な証拠なしに何かが機能しておらず、特にメモリ不足が疑われる場合は、OOMキラーとしても知られるアウトオブメモリキラーをチェックする価値があります。以下をお勧めします。
dmesg|egrep -i "memory|oom|kill"
編集:便宜上、これを標準的なインスタント診断リストに追加します。
cat /etc/lsb-release
uptime
df -h /
free
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc
アップグレード中ではなく、バージョン 3.2.0 のクリーンインストールを実行中に同じ問題が発生しました。
@RBoy と同様に AWS EC2 を使用しています。
古いフォーラムでは何も役立つ情報が得られなかったため、3.2.0 ではなく 3.1.5 をインストールする方法を探しています。
更新:
すみません、これを見つけました。
3.1.5のフレッシュインストールを、リンクで言及されているタグメソッドを使用して行うことができたかどうか、ぜひ知りたいです。試されたら、ぜひ投稿してください。
1GBのシステムへの3.2.0のインストールについては、これを試すことができます。SWAPサイズを8GBに設定して、それが機能するかどうか確認してください。おそらく非常に遅くなるでしょうが、機能するかもしれません。
ご丁寧なガイダンスをありがとうございます。
先日、Discourse 3.15 Docker バージョンのクリーンインストールを完了しました。私のようなAWS EC2無料利用枠を使用しているユーザーにとって、特にプロセスがどれほど簡単だったかを共有したいと思います。
私の経験に基づいた簡潔なガイドを以下に示します。
-
/var/discourse/containers/app.ymlにある Discourse 設定ファイルに移動します。 -
paramsセクションで、目的の Discourse バージョンに合わせて version パラメータを更新します。たとえば、次のようになります。params: # ... ## Specify the Git revision for this container (default: tests-passed) version: v3.1.5 # Use the specific tag name here -
変更を保存してエディタを終了します。次に、次のコマンドを実行して Discourse アプリケーションを再構築します。
/var/discourse/launcher rebuild app
このプロセスは私にとってシームレスに機能し、低コストまたはゼロ予算の Discourse セットアップを維持することが完全に可能であることを証明しました。
このガイドが、Discourse のインストールを効率的かつ費用対効果の高い方法で管理したいと考えている他の人々を支援できれば幸いです。