こんにちは、皆さん。
このオプションについて質問があります。app.yml ではデフォルトでコメントアウトされており、「ソートのパフォーマンスを向上させることができますが、接続ごとにメモリ使用量が増加する」と記載されていますが、これは具体的に何を意味するのでしょうか？接続数に依存するのでしょうか？db_work_mem とは何ですか？db_shared_buffers や UNICORN_WORKERS のように、Discourse をインストールする際に自動的に設定されるものなのでしょうか？これを有効にするのは安全策なのか、それとも上級者向けの設定なのでしょうか？
現在の設定は以下の通りです：
#db_work_mem: "40MB"
サーバー構成は以下の通りです：
Vultr High Frequency Compute 2 vCore, 4096 MB
ご回答いただければ幸いです！
これは複雑な問題です。詳細については、PostgreSQL のドキュメントを検索してください。チューニングに関するトピックはここにあります。
デフォルト設定は、概ね適切に機能します。
問題が発生している場合は、その問題の内容、トラフィック量、データベースのサイズについて説明してください。
Jay、ありがとう！ 実は、単に興味があっただけです。フォラムのパフォーマンスを向上させる方法を探っていたのですが、問題を引き起こす可能性があるなら、コメントアウトしたままにしておく方が良いかもしれません。
つまり、これを有効にすると、チューニングが適切でない場合やトラフィックが増加した場合、メモリ不足になる可能性が高いのでしょうか？私の理解は合っていますか？
work_mem(integer)クエリ操作（ソートやハッシュテーブルなど）が一時的なディスクファイルへの書き込みを開始する前に使用できる基本の最大メモリ量を設定します。単位を指定せずに値を指定した場合、キロバイトとして扱われます。デフォルト値は 4 メガバイト（
4MB）です。複雑なクエリの場合、複数のソート操作やハッシュ操作が並列で実行される可能性があることに注意してください。各操作は、一時的なファイルへのデータ書き込みを開始する前に、この値で指定された量のメモリを使用できるのが一般的です。また、複数のセッションが同時にそのような操作を実行している可能性もあります。したがって、使用されるメモリの総量はwork_memの値の何倍にもなる可能性があります。この事実を考慮して値を選択する必要があります。ソート操作はORDER BY、DISTINCT、マージ結合に使用されます。ハッシュテーブルは、ハッシュ結合、ハッシュベースの集約、INサブクエリのハッシュベース処理に使用されます。ハッシュベースの操作は、同等のソートベースの操作よりも一般にメモリ利用量に敏感です。ハッシュテーブルに使用可能なメモリは、
work_memにhash_mem_multiplierを掛けることで計算されます。これにより、ハッシュベースの操作は通常のwork_memの基本量を超えるメモリを使用することが可能になります。
作業メモリをコメントアウトされたデフォルト値の2倍に増やすと、役立つことがあります。インデックスが大きい大規模なサイトでは効果があると思いますが、確信はありません。設定を高くしすぎてサイトを壊した経験もあります。
チューニングを試してみたい場合は、Prometheus プラグインを確認し、Grafana で見やすいグラフを作成してみてください。
db_work_memを計算するためのこの式を見つけました。
デフォルトでは100の接続を想定して設定されています。
総RAM * 0.25 / max_connections
私の環境では 4096MB * 0.25 / 100 = 約10MB となります。
postgres.template.ymlテンプレートでは、デフォルトでdb_work_mem: "10MB"と設定されており、おそらくこの式に基づいて計算されているのでしょう。現在の最大値は10MBだと思います。ありがとうございました、Jay
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.