メモリ使用量について、サイト設定オプションとして調整できるようにすることは可能でしょうか？現在、チューニングは2Gに設定されています（編集：おっと、間違っていました、後述します）—以前は4Gでした—しかしながら、推奨されるハードウェア構成は1G＋スワップです。Rubyの使用量が実際に2Gに達した場合、1Gのノードはページングが頻発する恐れがあるように思われます。
アップグレードログより：
Migrating default
Seeding default
*** Bundling assets. This will take a while ***
$ RUBY_GC_MALLOC_LIMIT_MAX=20971520 RUBY_GC_OLDMALLOC_LIMIT_MAX=20971520 RUBY_GC_HEAP_GROWTH_MAX_SLOTS=50000 RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=0.9 bundle exec rake assets:precompile
Purging temp files
Bundling assets
これらの設定が現代の Ruby でどれほど関連性があるかはわかりませんが、@sam が最もよくご存じでしょう。
あの、失礼ですが、それは 2G ではなく 20M です。私が思っていた状況とは全く異なります。（編集：もっとひどいです！下記をご覧ください）
20Gで試してみてください。
Discourse のメモリ使用量は予測可能であるため、調整すべきパラメータは Unicorn ワーカーの数です。
1GB のサーバーの場合、デフォルトで 2 つのワーカーが設定されます。この少量のメモリでも正常に動作するはずです。
確かに、フォーラムとして動作している間はそうでした。しかし、これはそれとは異なります！
アップグレード中は、一部のタスクが Ruby に対してこれらの環境変数を指定します。
はい、アップデート中は、非常に低スペックなマシンでのメモリ不足によりアップグレードが失敗しないよう、それらの変数を設定しています。
はい、私の観察では、いくつかのケースでは制限が高すぎる可能性があります。そのため、設定可能にできないか検討しています。
この手順は長年にわたり多数テストしており、1GB の VPS を使用する小規模なコミュニティでも問題なく機能することをお約束します。アップグレード中にメモリを確保するため、追加の Unicorn ワーカーを終了させる機能も備えています。
このコミットから由来するコードはこちらで確認できます：
Digital Ocean のドロップレットで失敗を再現できる場合は、喜んで調査いたします。
これが必須である場合は、プラグンをフォークしてご自身のニーズに合わせて調整してください。
ありがとうございます、画像が見えてきました。（重要な点が2つあります。これらのGC設定はアップグレード用に調整されたものであり、単位はバイトです。現在の制限は20MBに設定されています。また、以前のスレッドには、有益で興味深い詳細が記載されています。現在はアクセスできないためアーカイブリンクになっています。）
そのトピックを復活させるべきでしょうか、@sam？歴史的価値があるのか、それとも不要なものですか？
確かに時代遅れです。最新の Ruby には複数の malloc 制限があります。これは歴史的価値のある興味深いトピックですが、トップに大きな「時代遅れ」の表示を付ける必要があります。
当社のアップグレードは既に限界まで最適化されています。これ以上できることは、可用性を低下させることだけです。メモリが極めて制約されている場合、アップグレード時に停止を受け入れる必要があります。