Azure Database for PostgreSQL灵活服务器中的故障排除指南是什么?

在 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 参考线。