在 PostgreSQL 上诊断性能问题通常意味着手动关联四件事:平台指标、会话快照、查询统计信息和服务器日志。 每个都位于不同的地方,使用不同的时间轴,并且需要各自的查询语言。
故障排除指南会为你实现这种关联。 每个指南针对一类问题,将相关遥测提取到单个视图中,并将其布局为诊断路径:确认症状,找到原因,应用修复。 它们已内置在 Azure 门户中的你的服务器上,因此无需部署,除了你已支付的 Log Analytics 数据引入费用外,不会产生任何额外费用。
指南能提供而指标图表无法提供的内容
CPU 指标显示 CPU 使用率为 95%。 它不能告诉你 为什么。 这些参考线旨在缩小这一差距:
- 它们归因。 图表将资源峰值链接到负责的特定查询 ID、进程 ID、等待事件或服务器参数。
- 它们进行解释。 每个图表都配有关键阈值说明(哪些属于健康范围、哪些需要调查、哪些属于严重情况),因此你不必凭记忆记住 10 亿个事务 ID 这个数量才是需要警惕的。
- 他们建议。 每个选项卡最后都会列出针对该选项卡所发现问题的操作措施,分为立即缓解措施和长期修复方案。
- 他们警告说。 横幅会提示遥测数据缺失和已检测到的问题,因此空白图表不会被误认为系统一切正常。
选择指南
从可以观察到的症状开始,通常是从指标警报或服务器 “概述 ”页开始。
| 您的症状 | 打开本指南 | 它回答 |
|---|---|---|
| CPU 使用率高或飙升 | 排查 CPU 使用率过高问题 | 这是工作负载增加、少量高开销查询、连接风暴、锁争用,还是过于频繁的日志记录? |
| 内存较高,或者出现内存不足错误 | 排查内存使用率过高的问题 | 内存参数是否过大、查询是否涉及太多数据,或者连接过多? |
| IOPS 或磁盘带宽饱和 | 排查 IOPS 使用率过高的问题 | 哪些查询导致了 I/O 负载?检查点是否过于频繁地触发?增加预配置的 IOPS 是否会有帮助? |
| 存储高峰或临时文件使用率较高 | 排查高临时文件利用率问题 | 哪些查询会溢写到磁盘,且 work_mem 的大小设置是否有误? |
| 膨胀加剧,或者查询计划变差 | 监控 autovacuum | autovacuum 是否跟得上,以及我离事务 ID 回卷还有多近? |
| 清空运行,但不会删除死元组 | 排查 autovacuum 阻塞因素和回绕风险 | 固定地平线是什么 xmin :长事务、孤立的已准备事务或复制槽? |
调查工作很少只停留在一份指南中。 这些指南会在常见成因形成连锁关系的地方进行交叉链接:
flowchart TD
A[Performance problem] --> B{Primary symptom?}
B -->|High CPU| CPU[High CPU]
B -->|High memory or OOM| MEM[High memory]
B -->|High IOPS| IOPS[High IOPS]
B -->|Storage or temp file spike| TMP[High temporary files]
B -->|Bloat or slow plans| AVM[Autovacuum monitoring]
CPU -->|Bloat suspected| AVM
IOPS -->|Bloat suspected| AVM
TMP -->|Memory pressure suspected| MEM
AVM -->|Vacuum runs, bloat persists| AVB[Autovacuum blockers]
如果无法判断哪个症状是主要症状(CPU、内存和 IOPS 通常一起上升),请从最接近其限制的资源开始,并将其他症状视为后果,直到数据另有说明。
组件指南一览
每个指南都分为多个选项卡。 这种顺序并非只是表面上的安排:它体现了诊断路径,即从界定症状的指标出发,延伸到可能解释该症状的工作负载,再深入到导致问题的具体会话、查询、等待事件或设置。
| 指南 | 按诊断顺序排列的选项卡 |
|---|---|
| 排查 CPU 使用率过高问题 | CPU � 工作负载 � 事务 � 长时间运行的事务 � 查询 � 用户连接 � 锁定和阻塞 � 等待 � 日志 � 洞察 |
| 排查内存使用率过高的问题 | 内存 � 工作负荷 � 会话 � 查询 � 用户连接 � 内存参数 |
| 排查 IOPS 使用率过高的问题 | 概述 � 工作负载 � 会话 � 查询 � 等待 � 检查点 � 存储 |
| 排查高临时文件利用率问题 | 存储临时文件工作负荷查询 |
| 监控 autovacuum | 膨胀 • 元组 • 清理并分析 • 自动清理活动 • 按表划分的自动清理 • 增强指标 • 清理限速概览 • 洞察 • 配置 |
| 排查 autovacuum 阻塞因素和回绕风险 | 紧急 autovacuum 和包装 Autovacuum 阻塞器 |
有几个构建模块会在各篇指南中反复出现,而且在任何地方含义都相同:
- 资源利用率:定义问题的指标。 使用它来确认症状,并在深入分析之前确定时间范围。
- 工作负载:读取元组活动相对于写入元组活动。 这是将“服务器正在执行更多合法工作”与“服务器效率较低的相同工作”分离的最快捷方法。
-
会话 和 长时间运行的事务:采样
pg_stat_activity快照,用于显示保存资源的进程 ID,区分连接年龄与事务年龄。 - 查询:来自 查询存储 的问题最突出的查询,按该指南所关注的维度排序,例如总持续时间、访问的数据量、I/O 时间或临时字节数。
- 等待:执行实际被什么所阻塞,并将其归因到正在等待的查询。
指南显示任何内容前需要满足的条件
引导内容会根据你选择启用的遥测数据生成。 未启用数据源的指南看起来与正常的服务器相同:空。 先启用这些源。
所有指南都要求将服务器日志发送到 Log Analytics 工作区。 各个指南还需要查询存储、增强的指标或特定的服务器参数。 有关各指南对应的矩阵和启用步骤,请参阅 使用故障排除指南。 有关每个源实际包含的内容,请参阅 故障排除指南的遥测参考。
局限性
- 最短时间窗口为一小时。 选择较短的范围将回退为在您所选结束时间结束的 1 小时捕获。 这些指南并不是为分秒必争的事件响应而设计的。
- 采样意味着可能会错过短暂事件。 对会话和等待数据进行采样,而不是连续记录。 短于采样间隔的尖峰可能不会留下任何痕迹。
- Autovacuum 导板、过滤器和端盖。 仅分析元组数超过阈值的表,并且每台服务器上也只分析数量有限的数据库。 总计与直接查询数据库所得结果不一致。
- 出于隐私保护,查询文本和用户名默认不予显示 门户显示数字标识符。 请参阅检索查询文本。
- 不建议在突发性能层上使用 查询存储,因为它自身的开销反而可能导致性能下降。
- 支持只读副本,但其行为与主实例不同。 参考线检测到副本后会进行调整。 写入工作负荷图表不可用,autovacuum 统计信息反映主节点的活动,因此针对主节点运行 autovacuum 参考线。