Tuning a Discourse server for performance

インストール ホスティング
1

Are there any guides (or Topics here on the forum) that provide tips on tuning a server that hosts Discourse sites for performance?

I ran the ./Discourse-set and it set a quarter of the ram (to 4096mb) and added 8 unicorns workers - but is there anything else we can do, or tweak these?

The server has 64GB ECC Ram and two 512GB NVMe SSDs (in a raid array). Looking at top, only around 5GB of memory us being used, with 57392484 avail Mem. It does run other non-Docker sites, but they don’t use up much of the resources and MySQL is already tuned for a large 2GB db. Load averages are generally below 1.0 (usually around 0.50 up to 1.0 with occasionally going over). No problems have been reported, but I am hoping to utilise as much of the server as possible.

I’m wondering whether to start by doubling db_shared_buffers… and what about #db_work_mem: "40MB" which is currently commented out.

All info/tips appreciated :smiley:

「いいね！」 3
2

フォーラムでもこの件を検索していました。

3

チューニングに関するトピックがいくつか（または過去に）ありました。成功したほとんどのトピックは、このトピックを除いて、利用可能なリソース、db_shared_buffers やその他の設定に関する正確な詳細、および問題点（htop やその他のツールの出力など）を提供していると思います。データベースのサイズはどれくらいですか？どのような問題が発生していますか？（新しいトピックを開始することをお勧めします）

「いいね！」 1
4

ありがとうございます。まだ問題はありません。メモリ使用量が高いことに気づきましたが、フォーラムが混雑しているわけではありません。私はただ、先を見越してリソースが最も使用されているものを確認することに慣れているだけです。これは3GBのVPSで、6コア@3.5GHzです。遅くはなく、非常に速いですが、メモリ使用量が将来の問題になる可能性があることがわかり、調整できることについて知りたいと思っています。

一般的なRuby on Railsアプリと最適化について、さらに読み進めます。再度、ありがとうございます。

「いいね！」 1
5

「使用量」をどの指標で測るかによりますが、それは正常な範囲かもしれません。しかし、3GBであれば、./discourse-setup を実行した場合、その推測はおそらく「十分」なので、あまり調整する余地はないでしょう。

「いいね！」 1
6 
free -h
              total        used        free      shared  buff/cache   available
Mem:          2.9Gi       1.8Gi       167Mi       100Mi       1.0Gi       895Mi
Swap:         1.0Gi       587Mi       436Mi

利用可能メモリは約900Mです。まだ問題ありません。しかし、問題があったからここに来たわけではありません。将来的に利用可能メモリが問題になった場合にどうすればよいか知りたいです。もちろん、メモリを増設する以外で。

image
image1469×365 105 KB

7

このレベルでは、実際に行えることは、より多くのRAMを投入することだけです。8GBまたは16GBのRAMをお持ちの場合は、いくつかの対処法があります。必要であれば、さらに1GBのスワップを追加することもできますが、おそらく問題ないでしょう。

./discourse-setup を実行した場合、2GBのスワップファイルが作成されます。再構築を行う際に問題が発生する可能性があります。

8

わかりました。インストールのデフォルトを次のように変更することで、利用可能なメモリ使用量をほぼ 2 倍にすることができました。
UNICORN_WORKERS: 8
から
UNICORN_WORKERS: 4
その後： sudo ./launcher rebuild app

現在、PostgreSQL の監視を設定しており、そこで何が起こっているかを確認します。

9

常にどこかのリソースがボトルネックになる時点はありますが、現在のサーバーは過剰に構成されているように見えます。

より多くのUnicornプロセスを使用すると、より多くのメモリを使用することになります。
サイトへのトラフィックが増えると、より多くのUnicornプロセスが必要になります。

すべてのUnicornプロセスがCPU使用率0.0%で、worker[0]のみが実際に何かを行っているように見えます。

Unicornの数を減らしてメモリを削減しました。どうせ使っていなかったようなので、それは良いことです。しかし、利用可能なメモリは実際には悪いことです。間違った変数を最適化しています。

未使用のメモリは何も購入しません。どうせ使用していないものにお金を払っているということです。常に2GBのメモリが利用可能であれば*、サーバーをダウンサイジングして費用を節約できます。

) Discourseの再構築にはより多くのメモリが必要になるため、再構築中に利用可能なメモリ量をチェックする必要があります。実際には、合計2GBを下回らないようにするか、Pfaffmanがすでに述べたように十分なスワップがあることを確認してください。

「いいね！」 1
10

間違いです。「何もしていない」空きメモリは悪いことですが、「利用可能な」メモリとは、簡単に解放できるシステムによって使用されているメモリのことで、これは良いことです。 :slight_smile:

または公式には：

利用可能なメモリ：スワップなしで新しいアプリケーションを開始するために利用可能なメモリの推定値。

出典：man free

以下のスクリーンショットによると、空きメモリはほとんど変化していません。したがって、システムのメモリのほぼすべてが使用されています。しかし、必要に応じて解放できる利用可能なメモリが増えたため、システムのスワップは減少します。

image
image1423×405 125 KB

…はい、トラフィックで変更が必要になるまで、使用されていないメモリは解放するようにしています。

重ねて感謝します。

11

ここで「悪い」とは、コストがかかるが何も得られないという意味だと思います。それはかなり一般的な考え方です。なぜなら、より多くのリソースが必要になると、それもより高価になるからです。そしてRAMはその方程式の中で高価な部分です。

そして、無駄にするお金があまりない場合、あまりにも多くのお金を払うのは愚かなことです（フィンランドの広告表現、悪気はありません :rofl: ）

「いいね！」 1
12

はい、その通りです。空きメモリに関してです。しかし、「利用可能なメモリは実際には悪いことである」…というのが、私がまさに指摘していたことです。:slight_smile: