2+2ではもう十分ではないようです…控えめな（大きな/派手なプラグインなどはない）Discourseインスタンスを管理していますが、本日、Emberが利用可能なRAMとスワップすべてを消費し、マシンを応答不能な状態にまで遅くするため、ブートストラップに失敗しています。さらに2GBのスワップを追加したところ、ピーク時のスワップ使用量が約2.5GBでブートストラップが完了しました。
うわっ、これは@davidの調査リストに載っている。
「いいね！」 5
@david が調査しており、現時点では 2GB で Docker の再構築は十分ですが、Web アップグレーダーを動作させるには不十分であることを確認しました。
私が提案したアイデアの 1 つは、Web アップグレーダー中にすべての Ruby プロセスをシャットダウンして、追加の 300〜500MB を節約し、アセットの事前コンパイルに十分な容量を残すことです。
セルフホスティングを行うユーザーにとって、長期的なアプローチとして、ブートストラップ済みのコンテナを出荷する ことが必要になる可能性があります。これはパンドラの箱を開けるようなもので、Web アップグレーダーがそれをどのように実現できるかという問題があります。Docker ソケットをマウントしたくはありません。
まさに難儀な状況です。
「いいね！」 2
私にはそうではありませんでした。
これは、基本的なクリーンインストールと実際の状況との比較ですか？
確かに、完全に一貫しているわけではありません。他のすべてがシャットダウンされていても、失敗する可能性があります。
残念ながら、最新のJavaScriptビルドツールとの戦いは負け戦です。これらはすべて、最新の開発者マシンの8GB以上のRAMで実行するように設計されており、1GBのVPSではありません 
いくつかの解決策を検討中です。たとえば、自動的にダウンロードできる事前構築済みのアセットを提供することです。大きな課題はプラグインです。なぜなら、それらは各サイトで異なり、現在はコアビルドに緊密に統合されているからです。
しかし、今のところ、Web UIの更新よりもCLIの完全な再構築の方が成功率が高くなるはずです。
「いいね！」 8
Jagsterと同様に、私のCLI駆動型Docker再構築では、2GBのRAM + 2GBのswapでは十分ではありません。さらに確認したところ、このインストールにあるプラグインはdocker_managerとdiscourse-prometheusのみです。どちらも、私が予想するように、emberに予期しない負荷をかけることはないでしょう。
最小スペックを変更する必要がある場合、それは残念ですが、アップグレードのたびにマシンが予期せずクラッシュする現在の状況よりはずっと良いでしょう。
「いいね！」 7
その場合、推奨スペックを少し上げる方が良いと思います。個人的には、リビルドがより信頼性の高いものになるのであれば、スワップをさらに2GB（あるいは4GB）追加することに抵抗はありません。少なくとも、小規模から中規模のコミュニティであれば、RAMが2〜4GBで日常的な運用が問題なく行える限りは。
「いいね！」 2
確かに、最近4c 4gインスタンスで実施した初期インストールは失敗しました。Edがスワップファイルを作成することを提案しました。スワップを作成するトピックを見つけ、4gのスワップを作成しました。これで、WebまたはCLIでの更新/アップグレードがすべて期待どおりに機能するようになりました。
私の意見では、Discourseは以前よりも多くのRAMを必要とすることを受け入れる必要があるかもしれません。
「いいね！」 3
zram は理にかなっていませんか？
このコミットを適用しました。https://github.com/discourse/discourse/commit/ae2bc240af434168aeebe73d550b1c979ca3a29b これで状況が改善されることを願っています。お試しいただき、結果をお知らせください！（約30分後にテストをパスするはずです）
ローカルのメモリ制約のあるDockerコンテナでテストしたところ、-m 1600m でビルドが成功するようになりました。この変更前は、最低でも -m 3000m が必要でした。
「いいね！」 12
テストビルド（クリーンインストール）を実行したところ、問題なく完了しました。現在、そのマシンには4GiBのRAM（Hetzner CAX11）と、同じサイズのswapファイルがあり、上記の2+2 GBセットアップよりも制約は少ないはずです。しかし、ビルド全体でのswapの使用量は最小限で、確認できた最大RAM使用量は約3.1GBでした。ほとんどの時間、約2GB前後で推移していたため、悪くないように見えます（ビルド時間はほぼ変わらず、約8分でした）。
「いいね！」 4
クリーンなインストールと再構築で、さまざまなセットアップで制御された実験を行い、特にvmオーバーコミットで実行した場合の違い（もしあれば）を確認したいのですが、残念ながら時間がありませんでした。
（オーバーコミットなしでは、フォークする大きなプロセスはメモリフットプリントが瞬時に増加する可能性があり、それは致命的になる可能性があり、ポーリングされたモニターには表示されません。オーバーコミットがあっても、メモリの増加はポーリング（htop、vmstat、またはその他のもの）に表示されないほど急速である可能性があります。）
オーバーコミットを有効にして実行しているかどうかをボランティアした人を私は見たことがありませんが、私の見解では、それはホスト構成の重要な側面です。
「いいね！」 1
ほとんどの人はそうしないと思います。
私は自分のインストールで自動的に設定しています。それでも、それに関する警告が表示されます。
ここでオーバーコミットは関係ありません。問題はプロセスが早期にOOMキルされることではなく、単に10ポンドの割り当てメモリを5ポンドの袋に詰め込もうとしているだけだからです。
overcommit_memory=2でDiscourseの再構築を実行することは現実的に不可能です。なぜなら、ember（おそらく他にもあるでしょう）は大量の仮想メモリを事前割り当て（私の記憶では、約80GBを見たと思います）するため、合理的なovercommit_ratio設定に常に違反するからです。overcommit_memory=1を設定しても助けにはなりません。なぜなら、ここでも、問題は過剰なVMMがプロセスをキルすることではなく、emberコンパイラによるひどく貧弱なメモリ管理だからです。
「いいね！」 1
あなたの分析には完全には同意できません！私の理解では、オーバーコミットはプロセスが触らないメモリを割り当てることを可能にします。それはOOM-killerの動作だけではありません。しかし、言うように、管理された実験を実行したいです。それが違いを生むものとそうでないものを見るためのより良い方法です。
私は4GBのRAMを持っており、多くのプラグインを使用しています（私が知る限りスワップファイルはありません）。あなたは何個のプラグインを持っていますか、そして普通の4GBのRAMは十分だと思いますか？
部分的には正しいですが、それでも無関係です。なぜなら、このトピックで議論されている問題は、プロセスが 触れる メモリを割り当て、システムが利用可能なメモリよりも多くを触ることで、顧客に見える障害を引き起こしているからです。
@david さんの変更後、メモリ要件が削減されたことを確認していただけますか？これで合理的な状態になるはずです。
次に大きな飛躍となるのは、プリコンパイルと分散プリコンパイル済みアセットです。そこに至るにはかなりの大きな変更が必要ですが、完了すればインターネットから大量の作業が削除されます。
「いいね！」 2
失礼ですが、そうではないと思います。フォークの失敗を示すログファイルを見たことがあります。このスレッドでは「メモリ要件」と言っていますが、私の見解では、それにはカーネルの仮想メモリの戦術も含まれます。明らかに、1つか2つの実験で、私がオーバーコミットについて正しいかどうか分かるでしょう。
それはプラグインなしの新しいビルドでした。いくつかのプラグインを有効にした別のビルドを試すか、一時的にスワップを無効にしてビルドが通るかどうかを確認してみます（ただし、時間が取れるまで少し時間がかかるかもしれません）。
「いいね！」 2