購入したVPSには3GBのRAMと1GBのパーティションスワップが付属していましたが、スワップファイルも設定すべきでしょうか、それともこれで十分でしょうか?
小さなDiscourseインスタンスにはこれで十分です。
つまり、実行速度が速いかどうかなどではなく、メモリの追加割り当てができないなどのエラーが発生するかどうか、ということです。私の質問は意味が通じますか?また、ファイルスワップをさらに優先度を低くして追加すると役立ちますか?念のためです。
より強力なVPS(少なくとも8GBのRAMを搭載したもの)を購入することをお勧めします。そうでなければ、時間を無駄にすることになります。
これは私の質問に答えていません。
8GB未満のRAMでDiscourseを実行することは想像できません。
Discourseチームメンバーが大丈夫だと言っています。それが大丈夫かどうかはわかりませんが。
幸運を祈ります。
Discourse-setup はメモリの問題をすべてフラグ付けします。
これも私の質問に答えていません。もしかしたら、私の質問の仕方が悪かったのかもしれません。
Digital Ocean の 2GB メモリ/50GB ディスクのドロップレットで比較的静かなフォーラムを運営していますが、問題なく動作しています。
私が Discourse をインストールした当時は、インストールガイドでは最低 1GB を推奨していましたが、途中でアップグレードしました。
フォーラムの規模や利用状況についてもう少し詳しく教えていただければ、より詳細な回答が得られると思います。
Discourse のインストーラーは自動的にスワップファイルを設定すると思いますが(手動では何もしていません)、これで質問の一部には答えられたと思います。
インストール時に、スワップがないことを検出した場合、2GBのものを作成すると思います。
編集: こちらの方が正確だと思います。
公式の最小サポートは1G RAM + 2Gスワップです。フォーラムが非常に小さい場合はこれで十分です。ただし、アップデートごとに少しずつ大きくなるため、いずれは十分ではなくなる時が来ると予想されます。
フォーラムが正しく機能し、クラッシュしないためには、RAMとスワップの合計が重要な数値です。
フォーラムが応答性があり、遅すぎないようにするには、より多くのRAMが推奨されます。したがって、1G RAM + 2Gスワップで十分な場合、3G RAM + 1Gスワップでも十分であり、パフォーマンスが向上する可能性があります。
私は2つのフォーラムを持っており、どちらもかなり小さいです。1つは1+2で実行され、もう1つは2+2で実行されます。
昨年、私はこれを書きました。
編集:ディスク容量に余裕があればスワップを追加してください。追加しない理由はありません。必要になる可能性があります。freeコマンドで使用量を確認でき、vmstatコマンドで実行中の状況を確認できます。しかし、平均使用量は興味深いものではありません。ピーク時の使用量が興味深いのです。
私の質問は、より理論的なものです。現時点ではフォーラムの人気を予測することはできません。私が理解しようとしているのは、どのようなシナリオでRAMが不足する可能性を軽減するために何をすべきかということです。Discourseが最もメモリを消費するのは、バックアップ作成時、画像のリサイズ時、管理コンソールからのアップデート時など、いつなのか私にはわかりません。全く見当がつきません。
そこで、メモリが不足した場合にDiscourseがクラッシュするのではなく、単に非常に遅くなるように、どのくらいのswapファイルを作成すべきかということです。すでに1Gのswapパーティションがあることを発見したので、3Gの物理メモリ+1Gのパーティションスワップで十分でない場合はどうなるか、ということを考えていました。さらに低い優先度(パーティションの1Gと比較して)で、数ギガバイトのswapファイルを作成すべきでしょうか。これで私の質問がより明確になったでしょうか。
もしそうであれば、そうです。インストールのREADMEファイルを更新すると役立ちます。インストールのREADMEでswapファイルを作成することが公式に言及されていた昔から来ているので、自動的に行われるのか、もう必要ないのか、あるいは公式のハウツーから削除された他の理由があるのか、今は少し混乱しています。
…では、1Gのパーティションベースのswapを検出した場合はどうなりますか?
では、私の質問の続きですが、2つのswap領域を持つことは良い考えでしょうか。1つはパーティションベースで、もう1つはファイルベースです。
問題ありません。複数のスワップ領域(または複数のスワップファイル)を持つことは全く問題ありません。
アップグレード中に最大のメモリピークが発生すると考えられます。そして、その際のリスクは、ヘルプが得られるまでフォーラムがダウンしてしまうことです。
また、オーバーコミットをより寛大な設定にすることも価値があります。まだ調整していない場合は、アップグレードログに既に記載されていることに気づくでしょう。
警告:overcommit_memoryが0に設定されています!メモリ不足の状態では、バックグラウンド保存が失敗する可能性があります。この問題を修正するには、'/etc/sysctl.conf’に’vm.overcommit_memory = 1’を追加してから再起動するか、このコマンド’sysctl vm.overcommit_memory=1’を実行して有効にしてください。
これは以前にも何度も言及されていますが、標準のDiscourseインストールレシピに追加することには抵抗があります。これはDockerイメージ内では実行できず、ホストで実行する必要がある設定の一種です。
リスクを軽減することしかできません。資金が多ければ、より大きな程度でリスクを軽減できます。この質問はトレードオフの領域にあります!
ディスク容量が無制限であれば、何も考えずに4Gのスワップを追加するでしょう。害はありません。資金が無制限であれば、入手できる最大のRAMを搭載するでしょう。しかし、私の場合はそうではありません。
フォーラムが成長する可能性があると予想している場合は、最初から機械のサイズを決定するのではなく、時間の経過とともに実行に必要なリソースを増やすことを期待すべきです。
私はまだフォーラムに使用しているマシンのサイズを増やしていませんが、今年か来年には増やすだろうと予想しています。
そうです。私は定期的に2GBのスワップを持つ1GBと2GBのドロップレットをセットアップしており、それらは機能します。現在、再構築には多くのRAMが必要ですが、それは機能するはずです。
もっと想像力を働かせる必要があります。
私は、月に約100万回のページビューがあり、比較的大きなデータベースを持つサイトでのみ、それだけの量を実行します。
Discourse を最初にインストールしたときにこれを言及しました (Warnings: overcommit_memory and Transparent Huge Pages)。なぜこれを行う価値があるのですか、そして抵抗の理由はなぜですか?デフォルト設定は変更していません。
以前書いたものはこちらです。
特に
デフォルトでは、カーネルは満たせない割り当てを拒否します。この調整により、それらの割り当てを受け入れ、失敗を回避できるか、または割り当てが使用になるまで後で発生する可能性があります。
RAMとスワップの合計が十分に大きい場合は、この設定を変更する必要はありません。合計が大きくない場合は、変更すると役立つ可能性があります。
また
仮想メモリの量を増やすことです。(つまり、RAMとスワップの合計です。)RAMが不足すると、パフォーマンスの問題が発生し始めます。しかし、仮想メモリが不足すると、プロセスが開始されなかったり、終了したり、キルされたりします。それはひどいものです。
RAMとディスクの両方が小さい私たちの場合、多くのスワップを追加することはできませんが、2Gは良い最小値のようです。(16GのRAMがあれば、スワップは必要ないかもしれませんが、それは別の話です。問題は物事が失敗することである場合、重要なのは両方の合計です。)
抵抗については、この変更はredisの利益のためであり、ほとんどの人は必要としないという認識によるものだと思います。
編集:この最近のスレッドは、おそらくその一例であり、比較的小さなインスタンスがメモリを使い果たしましたが、overcommitは設定されていませんでした。しかし、overcommitを設定してもこの問題が解決したかどうかはわかりません。その人は8G RAMにアップグレードしました。
