Odoo 向け PostgreSQL パフォーマンスの最適化: チューニング、インデックス作成、モニタリング

適切に調整された PostgreSQL インスタンスは、デフォルト設定と比較して、Odoo の応答時間を 2 ～ 5 倍改善できます。 Odoo のパフォーマンスの問題のほとんどはデータベース構成に遡ります -- デフォルトの PostgreSQL 設定は、マルチユーザー ERP システムを強化するためではなく、リソースの使用量を最小限に抑えるために設計されています。

重要なポイント

• デフォルトの PostgreSQL 設定は 128MB の共有バッファのみを使用します -- 本番環境の Odoo には 25% の RAM が必要です
• 頻繁にクエリされる列のインデックスが欠落していると、テーブル全体のスキャンが発生し、ページの読み込みが遅くなります。
• PgBouncer による接続プーリングにより、データベース接続のオーバーヘッドが 80% 削減されます
• 定期的な VACUUM と ANALYZE によりテーブルの肥大化を防ぎ、クエリ プランを最適に保ちます

---

PostgreSQL 構成のチューニング

メモリ設定

postgresql.conf をハードウェアに適した設定で編集します。 16GB RAM を搭載したサーバーの場合、shared_buffers を 4GB (合計 RAM の 25%)、effective_cache_size を 12GB (合計 RAM の 75%)、work_mem を操作ごとに 64MB、maintenance_work_mem を 1GB、および wal_buffers を 64MB に設定します。

クエリ プランニングの場合、SSD ストレージの場合はrandom_page_cost を 1.1 に設定し (デフォルトは HDD を想定した 4.0)、SSD の場合は効果的_io_concurrency を 200 に、より正確なクエリ プランを実現するには、default_statistics_target を 200 に設定します。

サイズのガイドライン:

接続設定

max_connections を少なくとも Odoo ワーカー x 2 とバッファに設定します。 4 つのワーカーと 2 つの cron スレッドがある場合、少なくとも 12 の接続が必要です。管理ツール、監視、バックグラウンド タスク用の接続を追加します。値を 200 にすると、快適なヘッドルームが得られます。

---

Odoo のインデックス作成戦略

欠落しているインデックスの特定

log_min_duration_statement を 500ms に設定して、低速クエリ ログを有効にします。次に、低速クエリ ログを分析して、テーブル全体のスキャンを特定します。

一般的な Odoo インデックス

Odoo は主キーと外部キーのインデックスを自動的に作成します。 sale_order(state)、account_move(state)、stock_move(state)、account_move(date)、sale_order(date_order) など、頻繁にフィルターされる列にインデックスを追加します。

複数列インデックスにより、一般的なフィルターの組み合わせが改善されます: account_move_line(account_id, date) およびstock_quant(product_id, location_id)。

ステータス列を含むテーブルの場合、アクティブなレコードに対する部分インデックスの方が効率的です。つまり、状態がキャンセルまたは完了していない行のみにインデックスを作成します。

---

EXPLAIN ANALYZE によるクエリ分析

実行計画を理解するには、遅いクエリに対して EXPLAIN (ANALYZE, BUFFERS) を実行します。探してください:

• Seq Scan: インデックスが欠落していることを示すフル テーブル スキャン
• ネストされたループ: 結果セットが大きいとコストがかかる可能性があります
• ソート: work_mem を超えるメモリ内ソートがディスクに流出
• バッファ共有読み取り: 高い値はデータがキャッシュされていないことを意味します

一般的なパフォーマンスの低下要因:

1. WHERE 句の列にインデックスがありません
2. Odoo ORM によって生成される大きな IN 句
3. 書き込み時に再計算をトリガーする保存された計算フィールド
4. 5 つ以上のテーブルを結合する複雑なレポート クエリ

---

バキュームとメンテナンス

PostgreSQL MVCC は、行が更新または削除されるときにデッド タプルを作成します。 VACUUM はこのスペースを再利用し、統計を更新します。

Odoo ワークロードの自動バキュームを構成します。最大ワーカー 3 人、60 秒の昼寝時間、バキューム スケール ファクタ 0.05、分析スケール ファクタ 0.02 で自動バキュームを有効にします。書き込み量の多いテーブル (account_move_line、stock_move、mail_message) の場合は、より積極的なテーブルごとの設定を設定します。

合計リレーション サイズとデッド タプル数をチェックして、テーブルの肥大化を監視します。 VACUUM FULL は、テーブルがロックされるため、極端な肥大化 (50% 以上のデッドスペース) の場合にのみ、またメンテナンス期間中にのみ使用してください。

---

PgBouncer による接続プーリング

PgBouncer は Odoo と PostgreSQL の間に位置し、接続をプールしてオーバーヘッドを削減します。 Odoo にはトランザクション プール モードを使用し、トランザクション間の接続を解放します。 default_pool_size を 40 に、max_client_conn を 200 に設定します。Odoo を PostgreSQL ではなく PgBouncer ポートに直接指定します。

---

モニタリング

重要な指標

• アクティブな接続: max_connections を十分に下回る値に保つ必要があります
• キャッシュ ヒット率: 99% 以上である必要があります
• トランザクション レート: ベースラインを設定し、異常を監視します
• 遅いクエリ数: しきい値を超えるクエリ
• レプリケーションラグ: リードレプリカを使用している場合
• ディスク使用量: データベース サイズの増加率
• テーブルの肥大化: テーブルごとのデッドタプル率

pg_stat_statements 拡張機能を使用して、クエリのパフォーマンスを経時的に追跡します。実行回数、合計時間、平均時間、および個別のクエリ パターンごとに返された行が記録されます。

---

よくある質問

Q: PostgreSQL がボトルネックかどうかを確認するにはどうすればよいですか?

スロークエリログを有効にして、Odoo パフォーマンスログを確認します。遅いリクエストのほとんどが遅いクエリに対応している場合は、チューニングが役に立ちます。クエリは速いが Odoo が遅い場合、ボトルネックはアプリケーション コードまたはネットワークにあります。

Q: Odoo には PostgreSQL レプリカを使用する必要がありますか?

リードレプリカは、レポート クエリをプライマリ データベースからオフロードします。 Odoo は読み取り/書き込み分割をネイティブにサポートしていないため、カスタム構成により読み取り専用クエリがレプリカにルーティングされます。これは主に、非常に大規模な展開に役立ちます。

Q: Odoo ではどの PostgreSQL バージョンを使用すればよいですか?

Odoo バージョンでサポートされている最新の安定リリースを使用してください。新しいバージョンには、クエリ オプティマイザーの改善とバキュームのパフォーマンスの向上が含まれています。現在の Odoo バージョンには PostgreSQL 16 または 17 が推奨されます。

Q: 適切なチューニングは実際にどの程度役立ちますか?

私たちの経験では、デフォルト設定から調整された構成に移行すると、通常、平均ページ読み込み時間が 40 ～ 60% 改善され、遅いクエリの頻度が 80 ～ 90% 減少します。改善は劇的かつ即時的です。

---

次は何ですか

PostgreSQL のチューニングは、Odoo のパフォーマンスに最も大きな影響を与える最適化です。まずはメモリ設定とインデックス作成から始めます。これら 2 つの変更だけでも、多くの場合、応答時間が半分に短縮されます。

データベースの最適化に関するヘルプについては ECOSIRE にお問い合わせ、継続的なパフォーマンス管理については Odoo サポート サービス をご覧ください。

---

ECOSIRE が発行 -- エンタープライズ ソフトウェア ソリューションによるビジネスの拡大を支援します。