# IPC:并行等待事件


以下 `IPC:parallel wait events` 表明会话正在等待与并行查询执行操作相关的进程间通信。
+ `IPC:BgWorkerStartup`：进程正在等待并行工作进程完成其启动序列。在初始化工作线程以执行并行查询时会发生这种情况。
+ `IPC:BgWorkerShutdown`：进程正在等待并行工作进程完成其关闭序列。这发生在并行查询执行的清理阶段。
+ `IPC:ExecuteGather`：在查询执行期间，进程正在等待从并行工作进程接收数据。当领导进程需要从其工作线程中收集结果时，会发生这种情况。
+ `IPC:ParallelFinish`：进程正在等待并行工作线程完成其执行并报告其最终结果。这种情况发生在并行查询执行的完成阶段。

**Topics**
+ [

## 支持的引擎版本
](#rpg-ipc-parallel-context-supported)
+ [

## 上下文
](#rpg-ipc-parallel-context)
+ [

## 等待次数增加的可能原因
](#rpg-ipc-parallel-causes)
+ [

## 操作
](#rpg-ipc-parallel-actions)

## 支持的引擎版本


Aurora PostgreSQL 的所有版本均支持此等待事件信息。

## 上下文


PostgreSQL 中的并行查询执行涉及多个进程协同工作以处理单个查询。当确定查询适合并行化时，领导进程会根据 `max_parallel_workers_per_gather` 参数设置与一个或多个并行工作进程进行协调。领导进程在各工作线程之间划分工作，每个工作线程独立处理自己的那部分数据，然后将结果收集回领导进程。

**注意**  
每个并行工作线程均作为一个单独的进程运行，其资源需求类似于完整的用户会话。这意味着，与非并行查询相比，具有 4 个工作线程的并行查询消耗的资源（CPU、内存、I/O 带宽）最多可达 5 倍，因为领导进程和每个工作进程都保持自己的资源分配。例如，诸如 `work_mem` 的设置单独应用于每个工作线程，可能会使所有进程的总内存使用量成倍增加。

并行查询架构由三个主要部分组成：
+ 领导进程：启动并行操作、划分工作负载并与工作进程进行协调的主进程。
+ 工作进程：并行执行查询各部分的后台进程。
+ 收集/收集合并：将来自多个工作进程的结果合并回领导进程的操作

在并行执行期间，进程需要通过进程间通信（IPC）机制相互通信。这些 IPC 等待事件发生在不同的阶段：
+ 工作线程启动：初始化并行工作线程时
+ 数据交换：当工作线程处理数据并将结果发送给领导进程时
+ 工作线程关闭：当并行执行完成且终止工作线程时
+ 同步点：当进程需要协调或等待其它进程完成其任务时

了解这些等待事件对于诊断与并行查询执行相关的性能问题至关重要，尤其是在可能同时执行多个并行查询的高并发环境中。

## 等待次数增加的可能原因


有几个因素可能导致与并行相关的 IPC 等待事件增加：

**并行查询的高并发性**  
当多个并行查询同时运行时，可能会导致资源争用和 IPC 操作的等待时间增加。这在事务量或分析工作负载较高的系统中尤其常见。

**并行查询计划不够理想**  
如果查询计划器选择效率低下的并行计划，则可能会导致不必要的并行化或工作线程间的工作分配不佳。这可能会导致 IPC 等待增加，尤其是对于 `IPC:ExecuteGather` 和 `IPC:ParallelFinish` 事件。这些规划问题通常源于过时的统计数据和表/索引膨胀。

**并行工作线程频繁启动和关闭**  
频繁启动和终止并行工作线程的短期查询可能会导致 `IPC:BgWorkerStartup` 和 `IPC:BgWorkerShutdown` 事件增加。这种情况经常出现在具有许多小型可并行查询的 OLTP 工作负载中。

**资源约束**  
有限的 CPU、内存或 I/O 容量可能会导致并行执行出现瓶颈，从而导致所有 IPC 事件的等待时间增加。例如，如果 CPU 饱和，则工作进程可能需要更长的时间才能启动或处理自己的那部分工作。

**复杂的查询结构**  
具有多个并行性级别的查询（例如，并行联接后跟并行聚合）可能会导致更复杂的 IPC 模式并可能增加等待时间，尤其是对于 `IPC:ExecuteGather` 事件。

**大型结果集**  
生成大型结果集的查询可能会导致 `IPC:ExecuteGather` 等待时间增加，因为领导进程将花费更多的时间来收集和处理来自工作进程的结果。

了解这些因素有助于诊断和解决与 Aurora PostgreSQL 中的并行查询执行相关的性能问题。

## 操作


当您看到与并行查询相关的等待时，这通常表示后端进程正在协调或等待并行工作进程。在执行并行计划期间，这些等待很常见。您可以通过监控并行工作线程使用情况、查看参数设置以及调整查询执行和资源分配，来调查并缓解这些等待的影响。

**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)

### 分析查询计划是否存在并行性效率低下问题


并行查询执行可能经常导致系统不稳定、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 命令在会话级别为特定查询禁用并行性。为了获得更广泛的影响，您可能需要通过调整数据库参数组中的相关参数，来在实例级别禁用并行性。有关更多信息，请参阅 [在 Amazon RDS 中修改数据库参数组中的参数](USER_WorkingWithParamGroups.Modifying.md)。

### 监控并行查询使用情况


使用以下查询来深入了解并行查询活动和容量：

检查活动的并行工作进程：

```
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 和内存的需求。

### 查看和调整并行查询设置


查看以下参数以确保它们与您的工作负载一致：
+ `max_parallel_workers`：所有会话中并行工作线程的总数。
+ `max_parallel_workers_per_gather`：每个查询的最大工作线程数。

对于 OLAP 工作负载，增加这些值可以提高性能。对于 OLTP 工作负载，通常首选较低的值。

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

### 优化资源分配


监控 CPU 利用率，如果 vCPU 的数量一直很高，并且应用程序从并行查询中受益，请考虑调整 vCPU 的数量。确保有足够的内存可用于并行操作。
+ 使用性能详情指标来确定系统是否受到 CPU 限制。
+ 每个并行工作线程都使用自己的 `work_mem`。确保总内存使用量在实例限制范围内。

并行查询可能比非并行查询消耗的资源要多得多，因为每个工作进程都是一个完全独立的进程，它对系统的影响与额外的用户会话大致相同。在为此设置选择值时，以及在配置其它用于控制资源利用率的设置（例如 `work_mem`）时，应考虑到这一点。有关更多信息，请参阅 [PostgreSQL 文档](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM)。资源限制（例如 `work_mem`）单独应用于每个工作线程，这意味着跨所有进程的总利用率可能比针对任何单个进程的正常利用率高得多。

如果工作负载高度并行化，可以考虑增加 vCPU 数量或调整内存参数。

### 调查连接管理


如果遇到连接耗尽的情况，请查看应用程序连接池策略。考虑在应用程序级别实现连接池（如果尚未使用）。

### 查看和优化维护操作


协调索引创建和其它维护任务，以防止资源争用。考虑将这些操作安排在非高峰时段。避免在用户查询负载较高的时期安排繁重的维护工作（例如并行索引构建）。这些操作可能会消耗并行工作线程并影响常规查询的性能。