# IPC:parallel 待機イベント
<a name="rpg-ipc-parallel"></a>

以下の `IPC:parallel wait events` は、セッションが並列クエリ実行オペレーションに関連するプロセス間通信を待機していることを示します。
+ `IPC:BgWorkerStartup` - プロセスは、並列ワーカープロセスが起動シーケンスを完了するのを待機しています。これは、並列クエリ実行のためにワーカーを初期化するときに発生します。
+ `IPC:BgWorkerShutdown` - プロセスは、並列ワーカープロセスがシャットダウンシーケンスを完了するのを待機しています。これは、並列クエリ実行のクリーンアップフェーズ中に発生します。
+ `IPC:ExecuteGather` - プロセスは、クエリの実行中に並列ワーカープロセスからデータを受信するのを待機しています。これは、リーダープロセスがワーカーから結果を収集する必要がある場合に発生します。
+ `IPC:ParallelFinish` - プロセスは、並列ワーカーが実行を終了して最終結果を報告するのを待機しています。これは、並列クエリ実行の完了フェーズ中に発生します。

**Topics**
+ [サポート対象エンジンバージョン](#rpg-ipc-parallel-context-supported)
+ [Context](#rpg-ipc-parallel-context)
+ [待機時間が増加する原因の可能性](#rpg-ipc-parallel-causes)
+ [アクション](#rpg-ipc-parallel-actions)

## サポート対象エンジンバージョン
<a name="rpg-ipc-parallel-context-supported"></a>

この待機イベント情報は、Aurora PostgreSQL のすべてのバージョンでサポートされています。

## Context
<a name="rpg-ipc-parallel-context"></a>

PostgreSQL での並列クエリの実行では、複数のプロセスが連携して単一のクエリを処理します。クエリが並列化に適していると判断されると、リーダープロセスは `max_parallel_workers_per_gather` パラメータ設定に基づいて 1 つ以上の並列ワーカープロセスと連携します。リーダープロセスはワーカー間に作業を分割し、各ワーカーは担当するデータ部分を個別に処理します。結果はリーダープロセスに収集されます。

**注記**  
各並列ワーカーは、フルユーザーセッションと同様のリソース要件を持つ個別のプロセスとして動作します。並列クエリで 4 つのワーカーが連携する場合、リーダープロセスと各ワーカープロセスの両方が独自のリソース割り当てを維持するため、非並列クエリと比較してリソース (CPU、メモリ、I/O 帯域幅) を最大 5 倍消費する可能性があります。例えば、`work_mem` のような設定は各ワーカーに個別に適用されるため、すべてのプロセスにわたって合計メモリ使用量が乗算される可能性があります。

並列クエリアーキテクチャは、以下の 3 つの主要コンポーネントで構成されます。
+ リーダープロセス: 並列オペレーションを開始して、ワークロードを分割し、ワーカープロセスと連携するメインプロセス。
+ ワーカープロセス: クエリの一部を並行して実行するバックグラウンドプロセス。
+ ギャザー/ギャザーマージ: 複数のワーカープロセスの結果をリーダーに戻してまとめるオペレーション。

並列実行中、プロセスはプロセス間通信 (IPC) メカニズムを介して相互に通信する必要があります。これらの IPC 待機イベントは、以下のさまざまなフェーズで発生します。
+ ワーカーの起動: 並列ワーカーを初期化するとき
+ データ交換: ワーカーがデータを処理し、結果をリーダーに送信するとき
+ ワーカーのシャットダウン: 並列実行が完了し、ワーカーを終了するとき
+ 同期ポイント: プロセス間で連携する必要があるとき、または他のプロセスがタスクを完了するまで待機する必要があるとき

これらの待機イベントを理解することは、特に複数の並列クエリが同時に実行中となる可能性が高い同時実行環境において、並列クエリの実行に関連するパフォーマンスの問題を診断するために重要です。

## 待機時間が増加する原因の可能性
<a name="rpg-ipc-parallel-causes"></a>

並列関連の IPC 待機イベントの増加には、いくつかの要因が関係します。

**並列クエリに伴う高い同時実行性**  
多数の並列クエリを同時に実行すると、リソースの競合が発生し、IPC オペレーションの待機時間が長くなる可能性があります。これは、トランザクション量が多いシステムや分析ワークロードで特によく見られます。

**最適ではない並列クエリプラン**  
クエリプランナーで非効率的な並列プランを選択すると、ワーカー間での不要な並列化や作業分散の低下につながる可能性があります。その結果、特に `IPC:ExecuteGather` イベントと `IPC:ParallelFinish` イベントで、IPC 待機時間が長くなることがあります。こうしたプランニングの問題は、多くの場合、古い統計情報やテーブル/インデックスの肥大化が原因です。

**並列ワーカーの頻繁な起動とシャットダウン**  
有効期間の短いクエリによる並列ワーカーの頻繁な開始と終了は、`IPC:BgWorkerStartup` イベントと `IPC:BgWorkerShutdown` イベントの増加につながる可能性があります。これは、多くの小さな並列化可能なクエリを含む OLTP ワークロードでよく見られます。

**リソースの制約**  
CPU、メモリ、または I/O 容量が制限されると、並列実行でボトルネックが発生し、すべての IPC イベントで待機時間が長くなる可能性があります。例えば、CPU が飽和していると、ワーカープロセスが作業の一部を起動または処理するのに時間がかかることがあります。

**複雑なクエリ構造**  
複数レベルの並列処理 (並列結合の後に並列集約が続くなど) を含むクエリは、特に `IPC:ExecuteGather` イベントの場合、IPC パターンが複雑化し、待機時間が長くなる可能性があります。

**大きな結果セット**  
結果セットが大きいクエリでは、リーダープロセスがワーカープロセスからの結果の収集と処理により多くの時間を費やすため、`IPC:ExecuteGather` の待機時間が長くなる可能性があります。

これらの要因を理解することは、Aurora PostgreSQL での並列クエリ実行に関連するパフォーマンスの問題の診断と対処に役立ちます。

## アクション
<a name="rpg-ipc-parallel-actions"></a>

並列クエリに関連する待機が生じた場合は、通常、バックエンドプロセスが並列ワーカープロセスを連携中または待機中であることを意味します。これらの待機は、並列プランの実行中によく発生します。これらの待機の影響を調査して軽減するには、並列ワーカーの使用状況をモニタリングし、パラメータ設定を見直して、クエリの実行とリソース割り当てを調整します。

**Topics**
+ [非効率的な並列処理のクエリプランを分析する](#rpg-ipc-parallel-analyze-plans)
+ [並列クエリの使用状況をモニタリングする](#rpg-ipc-parallel-monitor)
+ [並列クエリ設定を確認して調整する](#rpg-ipc-parallel-adjust-settings)
+ [リソース割り当てを最適化する](#rpg-ipc-parallel-optimize-resources)
+ [接続管理を調査する](#rpg-ipc-parallel-connection-management)
+ [メンテナンスオペレーションを確認して最適化する](#rpg-ipc-parallel-maintenance)

### 非効率的な並列処理のクエリプランを分析する
<a name="rpg-ipc-parallel-analyze-plans"></a>

並列クエリを実行すると、システムの不安定性、CPU 使用率の急上昇、予測不可能なクエリパフォーマンスの変動が発生しがちです。並列処理によって特定のワークロードが実際に改善されるかどうかを徹底的に分析することが重要です。EXPLAIN ANALYZE を使用して、並列クエリ実行プランを確認してください。

プランの効率を比較するには、セッションレベルで並列処理を一時的に無効にします。

```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE <your_query>;
```

並列処理を再度有効にして比較します。

```
RESET max_parallel_workers_per_gather;
EXPLAIN ANALYZE <your_query>;
```

並列処理を無効にすると、より良い結果またはより一貫した結果が得られる場合は、SET コマンドを使用してセッションレベルで特定のクエリに対して並列処理を無効にすることを検討してください。より広範な効果を得るには、DB パラメータグループの関連するパラメータを調整して、インスタンスレベルで並列処理を無効にすることもできます。詳細については、「[Amazon RDS の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。

### 並列クエリの使用状況をモニタリングする
<a name="rpg-ipc-parallel-monitor"></a>

以下のクエリを使用して、並列クエリのアクティビティと容量を可視化します。

アクティブな並列ワーカープロセスを確認します。

```
SELECT
    COUNT(*)
FROM
    pg_stat_activity
WHERE
    backend_type = 'parallel worker';
```

このクエリは、アクティブな並列ワーカープロセスの数を示します。値が高い場合は、`max\$1parallel\$1workers` の設定値が高い可能性があるため、値を下げることを検討できます。

同時並列クエリを確認します。

```
SELECT
    COUNT(DISTINCT leader_pid)
FROM
    pg_stat_activity
WHERE
    leader_pid IS NOT NULL;
```

このクエリは、並列クエリを起動した個別のリーダープロセスの数を返します。ここで数値が高い場合は、複数のセッションで並列クエリを同時に実行中であることを示しているため、CPU とメモリの需要が増加する可能性があります。

### 並列クエリ設定を確認して調整する
<a name="rpg-ipc-parallel-adjust-settings"></a>

以下のパラメータがワークロードに適合していることを確認します。
+ `max_parallel_workers`: すべてのセッションにわたる並列ワーカーの合計数。
+ `max_parallel_workers_per_gather`: クエリあたりの最大ワーカー数。

OLAP ワークロードの場合、これらの値を増やすと、パフォーマンスが向上する可能性があります。OLTP ワークロードの場合は、一般的に値を低く設定することが推奨されます。

```
SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;
```

### リソース割り当てを最適化する
<a name="rpg-ipc-parallel-optimize-resources"></a>

CPU 使用率をモニタリングし、値が一貫して高い場合や、アプリケーションが並列クエリのメリットを得られる場合は、vCPU の数を調整することを検討してください。並列オペレーションに十分なメモリが使用可能であることを確認します。
+ Performance Insights メトリクスを使用して、システムが CPU の処理能力に制約されているかどうかを判断します。
+ 各並列ワーカーは独自の `work_mem` を使用します。合計メモリ使用量がインスタンスの制限内であることを確認します。

並列クエリは、非並列クエリよりもかなり多くのリソースを消費する可能性があります。各ワーカープロセスは完全に独立したプロセスであり、別のユーザーセッションを追加するのとほぼ同じ影響をシステムにもたらすためです。この設定の値を選択したり、リソース使用率を制御する他の設定 (`work_mem` など) を構成したりする場合は、この点を考慮に入れる必要があります。詳細については、[PostgreSQL ドキュメント](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM)をご参照ください。`work_mem` などのリソース制限は各ワーカーに個別に適用されるため、すべてのプロセスにわたる合計使用率は、単一のプロセスにおける通常の使用率よりも大幅に高くなる可能性があります。

ワークロードを高度に並列化する場合は、vCPU を増やすか、メモリパラメータを調整することを検討してください。

### 接続管理を調査する
<a name="rpg-ipc-parallel-connection-management"></a>

接続が不足している場合は、アプリケーション接続プーリング戦略を見直します。接続プーリングをまだ使用していない場合は、アプリケーションレベルで実装することを検討してください。

### メンテナンスオペレーションを確認して最適化する
<a name="rpg-ipc-parallel-maintenance"></a>

インデックスの作成やその他のメンテナンスタスクを調整して、リソースの競合を防ぎます。これらのオペレーションは、オフピーク時間帯にスケジュールすることを検討してください。ユーザークエリの負荷が高い間は、負荷の高いメンテナンス (並列インデックスのビルドなど) をスケジュールしないでください。これらのオペレーションは並列ワーカーを消費し、通常のクエリのパフォーマンスに影響を与える可能性があります。