# 等待事件排查总图

> 从一张 pg_stat_activity 快照走向下一步安全动作的决策树。
---

这张图刻意保守：先保全证据，再区分预期空闲与真正停滞，最后进入各类别的专项排查。

```mermaid
flowchart TD
  A[采集 pg_stat_activity] --> B{wait_event 为空？}
  B -- 是 --> C[后端可能在用 CPU 或处于探针之间]
  B -- 否 --> D{Activity 或 Client？}
  D -- 是 --> E{空闲状态或预期的后台主循环？}
  E -- 是 --> F[通常正常；检查未结束事务与连接规模]
  E -- 否 --> G[检查客户端背压、网络与应用责任方]
  D -- 否 --> H{Lock 或 BufferPin？}
  H -- 是 --> I[构建阻塞链，定位根阻塞者]
  H -- 否 --> J{IO？}
  J -- 是 --> K[关联 pg_stat_io、文件系统延迟与负载阶段]
  J -- 否 --> L{LWLock？}
  L -- 是 --> M[重复采样，确认单个发热的内部资源]
  L -- 否 --> N[检查 IPC 对端或 Timeout 策略]
  I --> O[选择影响最小且有边界的动作]
  K --> O
  M --> O
  N --> O
```

## 最小证据包 {#bundle}

- 两张或更多带时间戳的快照。
- `pid`、`backend_type`、`state`、查询时长、事务时长、等待类型和名称。
- 每个等待后端的 `pg_blocking_pids(pid)`。
- 精确的 PostgreSQL 大版本与小版本。
- 负载标记：发布、批处理、检查点、清理、备份、DDL 或故障切换。

> [!WARNING]
> 不要只因为某个等待出现频繁就终止后端。健康集群里，`Activity`、许多 `Client` 与计时器等待本来就可能占据多数样本。