多くの人々が、OdooとPgBouncerをどのような条件で使用すべきか、特定の設定を実装する必要があるかどうかを尋ねています。

したがって、この記事を使用してこれらの質問に答え、OdooとPgBouncerのセットアップについて以前の記事よりも詳しく説明します。 以前の記事では、Odooでのビッグデータの処理方法について説明しました。 ここでは、PgBouncerとは何か、Odooの実装でいつ、なぜ使用する必要があるのか、パフォーマンスチューニングパラメータの推奨事項、および注意点について説明します。

さあ始めましょう。

目次

PgBouncerとは何ですか？

なぜPgBouncerを使用する必要がありますか？
Odooの実装でいつPgBouncerを使用するべきですか？
Odooとの典型的なPgBouncerの使用例
期待されるPgBouncerのパフォーマンス向上は何ですか？
Odooのパフォーマンス指向のセットアップの初期推奨事項
パラメータを理解し、パフォーマンスを調整するための推奨事項
Understanding the parameters and tuning performance accordingly
PgBouncerの主な設定の理解
システム間の一貫性
注意して使用する

PgBouncerとは何ですか？

PgBouncer は、PostgreSQLデータベース用の軽量なコネクションプーラーです。その主な目的は、データベースサーバーのパフォーマンスとスケーラビリティを向上させるために、クライアント接続のプールを管理することです。

アプリケーションがデータベースへの接続を要求すると、PgBouncerは新しい接続を作成するか、プール内の既存の接続を再利用します。

これにより、新しい接続を確立するオーバーヘッドが削減され、多数の同時接続によるデータベースサーバーのパフォーマンス問題を緩和するのに役立ちます。

さらに、PgBouncerは複数のデータベースサーバー間で負荷分散を行うように設定することができ、システム全体のパフォーマンスとスケーラビリティを向上させることができます。

なぜPgBouncerを使用する必要がありますか？

以下の理由から、PgBouncerなどのプーラーの使用をお勧めします。

• Odooは永続的な接続を使用しており、通常はクラスタで許可される実際の数よりも多くの接続を開いてしまいます。
• SLEEP状態に残っている無駄なOdooの接続は、重要なメモリをブロックし、ロックします（たとえば、pg_activityのSTATEとRESの列を参照してください）。
• PostgreSQLのメモリ不足は、データベースと全体のOdooシステムのパフォーマンスに深刻な影響を与え、非アクティブなタスクがライブ物理メモリをトラップすることを強制します。

PgBouncerをOdooの実装と一緒に使用すると、優れたメモリ管理、より良い接続、および高いTPS /秒の比率による重い負荷と多くのユーザーの下での改善されたOdooの応答時間が保証されます。

いつPgBouncer-Odooソリューションを適用するべきですか？

通常、次の状況でのみPgBouncerをOdooと一緒に使用する必要があります：

• 同じDBクラスター上で多くの同時ユーザーまたはデータベースを持っています。
• データベースクラスターのメモリが常に不足しており、I/Oストレージに圧力がかかっています。
• 重い同時使用下でのPostgreSQLデータベースクラスターのパフォーマンスが不十分です。

Odooとの典型的なPgBouncerの使用例

PgBouncer-Odooの展開は、次のカテゴリのいずれかに該当する必要があります：

1. 多数のOdoo同時ユーザー。
2. 多数のオープンされたPostgreSQL接続。
3. スケーラブルなVM/インスタンス/コンテナOdooが一意でスケーラブルでないデータベースクラスターに面している分散Odooアーキテクチャ。
4. Odooデータベースへの異なる直接アクセス経路とクエリを含む複雑なアーキテクチャ（Odooによって管理されていない場合は直接のPostgreSQLアクセス）。

PgBouncerのパフォーマンスの向上はどの程度期待できますか？

以下は、より多くの同時リクエストにさらされた場合のクラスターのTPSのパフォーマンスを示すチャートです。

ソース：Percona

このデータは非常に信頼性があります。PgBouncerバージョン1.17.0とOdoo 16 Enterprise、およびPostgreSQL 14を使用した最新のパフォーマンステストでは、非常に類似した結果が得られています。予想通り、Pg-bouncerは同時スレッド/クライアントの数が増えるとより高いパフォーマンスを提供します。

Odooの場合、パフォーマンスの向上は約25以上の重いユーザーから始まります。 heavy users 以下の基準に応じて、

トピック	活用	説明
ユーザー	HIGH	ユーザー数が増えると、同時リクエストのボリュームも増えます。Odoo ORMは、ささいなユーザーアクションでも多数のステートメントを生成する傾向があるため、大規模なユーザーベースでは大量のSQLステートメントが生成されます。
複雑さ	MEDIUM	非常に複雑なリクエストは、サブクエリの起動、並列ステートメントの開始、新しい接続の開始により、より問題が発生しやすくなります。
ユーザーの活動/レート	高い	Odooで多くのアクションを行うアクティブなユーザーは、より多くの接続を開き、より多くのステートメントを生成します。

Odooのパフォーマンス指向のセットアップの初期推奨事項

PgBouncerを使用してOdooのパフォーマンスを最適化する場合、次のプラクティスに従うことをお勧めします。

1. ソース： ソースをコンパイルして独自のサービスを作成します。インプットとアウトプットを制御することで、apt-get installを使用するよりもはるかに優れた結果が得られます。
2. デプロイメントインスタンスの場所： クラスタとは別のインスタンスにPgBouncerをインストールしないでください。ただし、このクラスタがシステムレベルでアクセスできない場合（例：GCP CLOUD SQL、AWS RDSなど）。そうすると、OdooインスタンスからPostgreSQLクラスタへのアクセス時間が低下し、その間に4つのネットワークレイテンシが挿入されます。

a. OdooマシンからPgBouncerへの1つのレイテンシ。

b. PgBouncerからPostgreSQLへの1つのレイテンシ。

c. PostgreSQLからOdooへの戻り道にもう2つのレイテンシ。

• プーリング戦略： トランザクションプーリングのみを使用してください。他のモードを使用すると、Odooのロングポーリングと競合するか、PgBouncerの使用が無意味になります。
• 認証: TRUST auth_typeを使用してください：これにより、PostgreSQLのAUTHステージのオーバーヘッドのほとんどがバイパスされ、pg_hbaメカニズムの大部分が回避されます。一方、Odooユーザーのユーザー資格情報はメモリに保存され、OdooからPostgreSQLクラスターへの直接アクセスが許可されます。
• リスニングポート: PgBouncerがlocalhost（127.0.0.1）でのみリッスンするようにしてください。それ以外の場合、非常に高いセキュリティリスクを生成しています。PgBouncerをPostgreSQLサービスの外部に展開する必要がある場合は、リッスンするIPを制御してください。

Odooでメモリ管理と応答時間を向上させたいですか？

お手伝いいたします

パラメータを理解し、パフォーマンスを調整する

注意：PgBouncerは、正確に計算された比率と値で適切に設定された場合には非常に優れたツールです。正確なデフォルトの展開なしでデプロイすると、初期のパフォーマンスと状況が悪化し、サービスの障害を引き起こす可能性があります。

PgBouncerの主な設定を理解する

初期のpgbouncer.iniファイルから、以下に詳述された主要な概念に焦点を当てます：

a. サーバーチェック遅延

server_check_delay ⇒ 解放された接続を即座に再利用できるように保持する時間（サニティチェッククエリを実行せずに）。0の場合、クエリは常に実行されます。

これは、アイドル接続をどれだけ積極的にシャットダウンし、PostgreSQLクラスターからリソースを回収するかを定義します：

• もし入力するなら 30 、PgBouncerは待機します 30秒 Odooのステートメントの結果が表示された後、接続を切断する前に。
• もし入力するなら 0 、PgBouncerは待機せず、接続を即座に切断します IMMEDIATELY OdooとPostgreSQLのトランザクションが終了した後、最も攻撃的な設定です。

高い値（SQLのタイミングで30秒は高いと考えられています）の利点と欠点：

• 利点 ⇒ 不要なリソースは保持されません。PgBouncerはOdooが使用したすべての可能なメモリと接続を回収します。これは最適なメモリ最適化が可能であり、常に利用可能なRAMがより多くなることを意味します。

これはまた、接続がすぐに利用可能であることを意味します。したがって、リアルタイムで可能なすべての接続を回収するため、Odooの「接続切れ」の問題を最小限に抑えることができます。

• DRAWBACK ⇒ もしOdooから多くの類似の接続とリクエストが来る場合、接続を速く切断しすぎるとパフォーマンスが低下する可能性があります。なぜなら、接続を再度開く必要があるからです。

例えば、ウェブサイトの閲覧のような繰り返しのメカニズムでは、Odooのワーカーは匿名の訪問者と同じアクセスタイプを使用するため、ほとんど同じ接続を使用します。

b. Odooシステムのデフォルトプールサイズ設定

default_pool_size ⇒ この設定は、PgBouncerプーラー内のユーザー/データベースのペアごとに許可するサーバー接続の数を定義します。デフォルト値は20です。

注意: 設定する数値が低すぎると、パフォーマンスに悪影響を与える可能性があります。設定する数値が高すぎると、多くのオープンな接続を許可することになり、PgBouncerが非効率になります。

Odooでの正しい計算は何ですか？ おおよその計算をしましょう:

各Odooユーザーが少なくとも1つの接続を必要とすると仮定しましょう（ただし、ORMの必要に応じてOdooはより多くの接続を開く傾向があることは知っています）

また、重要なユーザーのうち30％だけが完全に同時に行動すると仮定しましょう。

そのため、リクエストのビジネスは、接続が長いか短いかに関係する変数であると仮定しましょう。

• ハイプロファイルユーザーからのより複雑なリクエスト（承認/一括移動/ダッシュボード）は、指数2を与えます
• 標準ユーザーからの一般ユーザーの要求（販売入力/発注入力/倉庫移動の生成および入出庫のフォローアップ）は、指標1を与えます
• 低関与のスタッフからのシンプルなユーザーの要求（参照のみ/小規模な操作/制限付きアクセスおよびその他の軽量ユーザー）は、指標0.5を与えます

丸めた計算は次のようになります

• 100で 重い パワーユーザー⇒（100 *（30％x2）= 60
• 300で 中程度の パワーユーザー⇒（300 *（30％x1）= 100
• 1000で 低い パワーユーザー⇒（1000 *（30％x0.5）= 150

したがって、Odooシステムの合計50人の同時ユーザーで、次のような仮定ができます

• 40 ヘビー パワーユーザー⇒（40 *（30％x 2）= 24
• 10 低 パワーユーザー⇒（10 *（30％x 0.5）= 2

その場合、推奨される default_pool_size 設定は24 + 2 = 26になります。

c. 最小プールサイズ

min_pool_size ⇒プールがこの値以下になると、プールにさらにサーバーコネクションが追加されます。この値は実質的にプールサイズで制限されるため、最小の接続数は最大の接続数を上回ることはできません。デフォルトの設定は0です。

この設定を使用すると、通常の負荷が完全な非アクティブ期間の後に突然戻ってきた場合のパフォーマンスとアクセス時間が向上します。

実際には、Odooでは、通常、昼休みと夕方の休憩中に2つの特定のダウンタイムが発生し、ほとんどのユーザーが同じビジネス時間に再開されます。

したがって、これは低使用期間と高使用期間、および高標準のユーザー同時性のある特定のタイプのOdoo展開に適しています。

Odooでの計算方法は？ 上記の場合、default_pool_sizeの設定を40％制限することをお勧めします。したがって、前述の50ユーザーの例に続いて、計算は次のようになります：26 - 40％= 18（切り捨て）

d. Max client conn

max_client_conn は許可されるクライアント接続の最大数です。増加する場合、ファイルディスクリプタの制限も増加する必要があります。

実際に使用されるファイルディスクリプタの数は、 max_client_conn よりも多いです。理論的な最大値は次のとおりです：

max_client_conn +（max pool_size * total databases * total users）

ただし、Odooの場合、データベースユーザーは接続文字列で指定されます（すべてのユーザーはodoo.confファイルで指定された「odoo」という同じユーザー名で接続します）。

したがって、理論的な最大値は次のとおりです：

max_client_conn +（max pool_size * total databases）

この計算を行うには、前のセクションで計算された値を先に使用する必要があります。

システム間の整合性

次の3つのシステム内で最大接続設定を設定する際に厳密なロジックを適用する必要性に注意してください

1. Odoo エンジン（odoo.conf内の odoo.conf 設定で db_maxconn ）
2. PgBouncer （pgbouncer.ini内の pgbouncer.ini 設定で max_client_conn ）
3. PostgreSQL (inside postgresql.conf with setting max_connections )

Word (2 sentences) of advice:

The Odoo max_connections parameter should NOT be smaller than the PgBouncer ’s.

PostgreSQL connections should NEVER be inferior to the PgBouncer それ以外の場合、接続不足とPostgreSQLの障害が発生する可能性があります。

注意して使用してください

過去に受け取ったメッセージや懸念事項は、送信者がここに何らかの魔法のレシピがあると確信していたようで、それが彼らのすべてのOdooのパフォーマンス問題を何とか解決するだろうと思っていたようです。

Odooの場合、PgBouncerとは無関係のアプローチの角度が他にも多くあります。例えば、

• 間違ったインフラストラクチャのセットアップ、仕様、または設定
• 弱いモジュール/フロー処理ロジックの設計
• テーブルの同時実行の誤管理
• クエリの計画の誤管理
• タプルの供給の誤管理
• 弱い、不足している、適応されていない、または冗長なインデックス戦略
• 重いステートメントの管理の欠如
• 弱いOdoo ORMコーディングおよび/またはカスタマイズされたアドオン。
• Odoo StudioによるETLおよびデータベースのパフォーマンスの損傷
• その他もろもろ

まとめると、PgBouncerはOdooとPostgreSQLのセッション管理に役立つミドルウェアです。

ただし、これは前述のケースにのみ適用され、それ以外の場合は複雑さ、余分なオーバーヘッド、パフォーマンスの低下につながります。

Odooのパフォーマンスの最適化に関する質問がある場合は、お気軽にお問い合わせください。 当社の専門チームにご連絡ください。 。