ClickHouse托管Postgres查询洞察新增等待事件

新增内容及其重要性

我们推出了Query Insights，帮助你找出开销高昂的查询，并了解其背后的 CPU、读取和写入情况。但找到慢查询只是全貌的一部分。数据库可能把时间花在磁盘 I/O、等待锁，或者仅仅是在 CPU 上繁忙。ClickHouse Managed Postgres 的 Query Insights 现在包含等待事件指标，因此你可以看到活跃会话在等待什么，以及这种等待随时间如何变化。细分视图展示每个等待类别的平均活跃会话数，以及每个类别在总负载中的占比。结合你的查询和资源指标，这有助于你缩小下一步调查的范围。

查看等待事件及其负载占比

在 Query Insights 中，按等待类型划分的活跃会话图表按 wait_event_type 对主库上的活动进行分组。每个条形显示该时间区间内活跃客户端会话的平均数量，并按 IO 和 Lock 等类别拆分。关于每种等待类型和事件的含义，参见 PostgreSQL 文档。

在下图中，锁等待占活动的最大份额，其次是 Timeout 和 CPU。这里的 CPU 指会话处于活跃状态且未报告等待事件；它并不是对 CPU 利用率的直接测量。

如果想进一步查看，将鼠标悬停在任意条形上，即可看到驱动每种等待类型的具体事件。

高亮区间有 25 个平均活跃会话，其中 13 个在等待锁。工具提示进一步拆分这些锁等待：4.5 个为 tuple，3.5 个为 transactionid，3 个为 relation，2 个为 advisory。

点击卡片打开 Waits 表。在这里你可以找到各个 wait_event 值、它们的平均活跃会话数，以及它们在总负载中的占比。

在所选范围内，四个 Lock 行合计约占负载的 42%。Relation 锁占 15.2%，tuple 锁占 12.4%，是该类别中最大的贡献者。

用两个额外指标理解锁争用

等待细分图旁边还有两个图表。Blocked sessions 显示等待锁的会话平均数量。Lock wait time 报告这些会话在被采样时已等待了多长时间，包含 p50、p95 和最大值。

在这些图表中，繁忙时段的大部分时间约有 9 到 12 个会话被阻塞，峰值约为 13 个。最大锁等待时间多次升至 100 秒以上，而 p50 保持在 10 秒以下。综合来看，这些图表展示了受影响的会话数量以及它们被阻塞了多长时间。

通过 Prometheus 监控

我们最近将 Query Insights 指标 添加到了 Managed Postgres Prometheus 端点。其中包括用于计算吞吐量和 平均延迟 的查询计数和总执行时间，以及 失败查询、返回或影响的行数、缓冲区活动 和 WAL 生成量。计数按操作拆分，因此你可以跟踪读写流量的变化。

等待事件也可通过 Prometheus 获取。你可以在 Grafana 中把 按等待事件划分的活跃会话 和 最大锁等待时间 与查询指标放在一起绘图，并对持续的锁争用设置告警。

这份 Prometheus 集成指南 涵盖身份验证和抓取配置。这样你就可以构建符合自身需求的自定义仪表盘和告警流水线。

使用 ClickHouse Agents 进行调查

ClickHouse Agents 可以同时查看等待事件、慢查询模式和服务指标，帮助你决定下一步调查什么。试着问：

我的 Postgres 数据库在等待什么，我接下来应该调查什么？

以下是 ClickHouse Agents 调试等待事件的一个示例：