アップグレードをいくつか行い、メモリエラーを解決する最も簡単な方法は、スワップを 4GB に倍増させることだと判断しました。欠点は、1GB のドロップレットには SSD が 25GB しかないため、そのうち 4GB をスワップに失うのはかなりの量であり、25GB しかない場合はすでに少し手狭になっていることです。
そのため、discourse-setup を変更してデフォルトを 3GB にすべきでしょうか？
どう思いますか、@Falco さん？
それで問題が解決するなら、私は全面的に賛成です。
「いいね！」 2
メモリ処理に影響する2つのカーネルチューナブルもインストールスクリプトで設定することを強くお勧めします。問題があると思われるすべての人々が、少なくとも良好なカーネル設定の出発点を持っていることがわかると良いでしょう。
「いいね！」 2
これは私には健全なアイデアのように思えます。専用のディスコースインスタンスでTHPがどのように役立つのか想像できませんし、overcommitはOOMを回避するのに役立ちます。
これらをそれぞれ個別に提供し、デフォルトの応答として設定し、デフォルト以外のオプションでオプトアウトできるようにすることを検討してみてはいかがでしょうか。
また、スクリプトは、変更を加える前に、設定を変更する必要があるかどうかを判断するためにsysctlを使用できます。誰かがすでに異なるファイルでこれらの変更を行っている場合、重複するオーバーライドを作成すると混乱する可能性があります。すべてのLinuxディストリビューションがそもそもメモリovercommitをオフにして出荷しているわけではないと思います。
if $(sysctl -n vm.overcommit_memory) != 1 ; then
....
fi
「いいね！」 3
カーネルチューナブルに関する重要なメッセージを薄める危険を冒して、2番目の考慮事項があります。現在のスクリプトは、低RAMマシンにのみスワップを作成します。これは間違いだと思います。スワップはRAMの有用性を最大化するために依然として役立つだけでなく、より重要なことに、誰かがDiscourseを大規模RAMマシンで速度や利便性のために作成してから、小規模RAMにダウンサイジングした場合に問題を引き起こす可能性があるためです。
セットアップは、すべてのケースでスワップを作成する必要があります（すでに十分な場合を除く）。複数のスワップファイルを持つことは有効であり、時には役立ちます。
「いいね！」 2
私が決定権を持っているわけではありませんが、私がセットアップしたマシンではそれらをセットアップしています。しかし、これはDiscourseをインストールする（ほとんどの）すべての人によって実行されるシェルスクリプトです。できるだけシンプルにする必要があります。Raspberry PiやMac、その他人々が試すであろうどんなナンセンスなことでも、これらの設定が機能することを確認していますか？そして、すでに設定されているかどうかをテストするために使用する方法は、すべてのプラットフォームで機能しますか？難しそうです。
私はdiscourse-setupを書きましたが、それに変更を加えるのは少し怖いと感じています。
常にスワップを作成するように提案するのは悪い考えではありません。おそらく、常に3GBまたは4GBのスワップを設定するように提案しますか？しかし、その場合、どのくらいの量ですか？かつて知っていた経験則は、RAMと同じサイズのswapを持つことでした。そして今、スワップを作成しない場合、唯一の選択肢はcontrol-cで終了することです。したがって、人々がスワップを作成するように強制するか、別のY/N質問を追加するか（これにより、discourse-setupを実行するスクリプトを変更する必要があります 
）、どちらかになります。ああ！または、--skip-swapスイッチで制御できるようにします。それは私には大丈夫そうです。スワップについて十分賢ければ、それをスキップするスイッチを見つけることができます。その警告メッセージにスイッチに関する注釈を追加できます。
そして、接続テストが失敗した場合に--skip-connection-testに関する注釈も追加するかもしれません。
すでにスワップが設定されている場合、彼らは自分が何をしているかを知っていると仮定するのは安全だと思います。
「いいね！」 1
ありがとうございます！そして、はい、完全に理解できます。私も同じように感じるでしょう。確かに、慎重な検討とテストが必要です。そしてそれは、少なくとも数社のホスティングプロバイダーの安価なマシン、そしてPiでも行われるでしょう。WindowsやMacについてはよくわかりません。それらがサポートされることが期待されているのであれば、おそらくそうでしょう。それらは開発マシンとして使用される可能性が高いと思いますが、それは別の話です。
確かに。おそらく、現時点で必要と思われる量で。それは一歩進んだように見えますが、これらのレポートがオーバーコミットの調整を含んでいるのかどうかを知らないことは、私を大いに悩ませています。以前の議論から、オーバーコミットが違いを生むことを私たちは知っていると確信しています。
そして、25Gインスタンス、さらに20Gインスタンスではディスク容量がタイトであることを知っています。私はそのようなマシンで実行しています。ディスク25G、RAM 1Gで、現在2Gのスワップが必要で、おそらく最近ではもっと必要です。そしてディスク20G、RAM 2Gで、現在1Gのスワップがあります。
これ以上のY/Nの質問は推奨しません。コマンドラインオプションの方が良い方法のように思えます。
このスクリプトを変更するのであれば、私は複数の1Gスワップファイルをお勧めします。なぜなら、それは柔軟性を最大化し、何も無駄にせず、その決定を下すのが最も簡単だからです。
私はそれほど確信がありません。ネイキッドUbuntuまたはDebianの最小インスタンスにすでにスワップがある場合（これは確認する必要があります）、十分でない場合は問題が発生し始めます。free を使用してRAM+スワップを測定し、サブ1G構成（AWS、おそらくOracle）に合わせて通常通り調整してから、合意された数まで1Gスワップファイルをいくつか追加する方がはるかに良いでしょう。現在のところ、カーネルのオーバーコミットが適切に設定されていれば、合計4Gで十分であることを願っています。
喜んでお手伝いします。
「いいね！」 2
うーん。ええ。私が調整したレポートにそれ（オーバーコミットの調整）が含まれているか確認すればよかったと後悔しています。
うーん。私は1つの方が良いと考えていますが、複数の方が柔軟性が増し、もしスワップがさらに必要になった場合にdiscourse-setupで別 のスワップファイルを追加できるようになる可能性があります。つまり、スワップの問題を「修正」するために、皆にdiscourse-setupを実行するように指示できるということです。そして、オーバーコミットの問題も同様に解決できるかもしれません。おそらく、私たちが気にかけているLinuxだけを対象に、それを明示的に試みるのが良いでしょう。
「いいね！」 2
同意しません。スワップは万能ではありません。VMコードを均一にするために重要だったこともありましたが、VMアルゴリズムは変更されました。
それは、もはや適用されない非常に古いカーネルコードのヒューリスティックに基づいています。
また、測定を検討する際には、zswapが使用されている場合にスワップとメモリを測定するために何をしたいのかさえわかりません。これはおそらく「まず害をなさない」というケースでしょう。
「いいね！」 2
「スワップが多すぎる」ことの唯一の欠点は、必要以上に多くのディスク容量を使用することだと確信しています。これは、ディスク容量を回復する必要がある場合に、段階的にスワップオフして削除できる、いくつかの適度なサイズのスイ ップファイルを用意する方が好ましい理由の1つです。また、Linuxはそれらを段階的に使用するのに合理的な仕事をしていると思います。
NAME TYPE SIZE USED PRIO
/var/local/swap/swapfile.1 file 1024M 863.6M -2
/var/local/swap/swapfile.0 file 1024M 4.6M -3
私たちが直面している状況は、安価なインスタンスはRAMとディスクスペースの両方が非常に限られており、Discourseは内部の非常に多くのパッケージが進化するにつれて、ますます多くのリソースを使用することです。しかし、それでも、月額料金を倍増または4倍にするだけで手を挙げることのできない人々を助けるために、賢くナビゲートする方法があると思います。
「いいね！」 1
スワップは十分に遅いため、現時点ではデフォルトの提案に1GB以上を追加する理由として「ほとんど空きがない」とは考えられません。専用のDiscourseインスタンスで経験したように、1GBのスワップはかなりの量です。
はい、デフォルトではLinuxはスワップを優先順位で利用し、複数のデバイスで同じ優先順位を使用して明示的にスワップをストライピングすることが可能です。しかし、小規模なサイトのために大量のスワップを追加しても、それほど価値はないと思います。
したがって、約10年経っても人々が2GBをたまにしか使い切らないのであれば、デフォルトを4GBではなく3GBにすることを提案します。また、専用のDiscourseインスタンスに必要なスワップ量は、実際にスワップアウトされるコンテンツはそれほど変化しないため、メモリが増えてもそれほど増加するはずではありません。
より多くのメモリでスワップを増やすという考え方は、主に汎用コンピューティングに由来しており、必要なRAMが多いほど、需要も大きくなるだろうという一般的な仮定に基づいています。しかし、専門的なDiscourseインスタンスのスワップ圧力は、そのパターンに従う可能性は低いと思います。
THPは、すべてのプラットフォームでサポートされているわけではない、huge pagesをサポートするプラットフォームに固有のものです。それを処理する一般的な方法は、それが存在するかどうかを確認することです。私が持っているRaspberry Piの1つで：
$ sysctl sys.kernel.mm.transparent_hugepage.enabled
sysctl: /proc/sys/sys/kernel/mm/transparent_hugepage/enabled に stat できません: ディレクトリまたはファイルが見つかりません
$ echo $?
255
対照的に、overcommitは過去数十年にわたるLinuxの一般的なVMパラメータです。同じRaspberry Piで：
$ sysctl vm.overcommit_memory
vm.overcommit_memory = 0
シェルでfreeの出力を解析するのは少し面倒です。procpsの元の作者として言えば、この目的のためには/proc/meminfoでSwapFreeを探すだけです。
「いいね！」 2
RAMサイズによるスワップのスケール変更は、コスト制約のある世界ではもはや良い計画ではないことに同意します。その次に歴史的に見られたアイデアは、RAMは巨大であり、スワップは不要であるということでした。その後、RAMのより良い利用を可能にするため、ある程度のスワップが有用であるという知恵が続きます。（制約のない世界では、単に膨大な量のRAMがありますが、それはニッチです。）
ここ数ヶ月で、メモリ不足の問題や再構築の失敗が増加しているのを目にしています。Webでのアップグレードは失敗するが、コマンドラインでは機能するという人が増えています。単純なサポートの観点から、そして製品の評判の観点から、通常の推奨事項と通常のセットアップを変更する必要があると思います。3Gのスワップが最もシンプルで最小限の変更であり、他に何も行わない場合はそれを行うべきだと思います。
しかし、私は依然として、複数の小さなスワップファイルの方が賢明な選択だと考えています。そして、そのことを示唆するサポートスレッドをここで目にしました。そして、RAM +スワップをサイズ設定しようとすることが最善だとまだ考えています。なぜなら、それが人々をトラブルに陥らせる制限要因だからです。その計算にはさまざまな方法があるかもしれません。通常の注意点として、保守可能で、理解しやすく、長持ちする戦術について言及します。
透過的な巨大ページについては、問題を引き起こすのは「透過的」であるということだと理解しています。カーネルは、パフォーマンスの低下と大きなメリットなしに、マージとデマージを繰り返して苦労する可能性があります。私は、巨大ページは小規模システムには不適切であると確信しています。
システムのサイズよりもワークロードの特性によるところが大きいです。RAMが1GBで、RAMの塊を持つ比較的安定したプロセスがあるシステムでは、デフォルトの2MB HUGEPAGESはTLBのスラッシングを減らし、パフォーマンスを向上させることができます。TLBは1GBのRAMのマッピングをカバーしきれません。これは一般的に、メモリを結合するCPU時間とTLBキャッシュミスとのトレードオフであり、1GBのマシンでもTHPからかなりの恩恵を受けることができるワークロードはたくさんあります。（無効にするという多くの推奨は、実装の初期段階からのものであり、それ以降大幅に改善されています。）DiscourseでTHPを無効にするという推奨は、1GBのRAMサイズのためではなく、Discourseが使用するディスク永続化を伴うRedisの使用に特有なものです。
https://redis.io/docs/management/optimization/latency/#latency-induced-by-transparent-huge-pages
残念ながら、Linuxカーネルで透過的なHUGE PAGESが有効になっている場合、Redisはディスクへの永続化のために
fork呼び出しの後に大きなレイテンシペナルティが発生します。HUGE PAGESが以下の問題の原因です。
…
「いいね！」 2