性能洞察

步骤一：定位异常时间段

在页面顶部选择时间范围，通过观察关键性能指标趋势图的异常波动，快速锁定问题发生的时间点。

• 重点关注：内存/CPU 使用率、会话连接数、TPS和IOPS的突发尖峰或急剧下跌。关于关键指标的详细解读，请参考附录：关键性能指标解读。

• 推荐操作：将鼠标悬停在任意趋势图上某一时间点，可放大该时间点进行更细粒度的分析。

步骤二：识别性能瓶颈

锁定异常时间段后，核心是分析平均活跃会话（AAS）图表。它将数据库负载按不同维度（如等待事件、SQL、来源主机等）进行可视化拆分，帮助您精确识别性能瓶颈的类型。关于AAS图表及各分析维度的详细解读，请参见附录：理解AAS（平均活跃会话）图表和附录：多维分析列表说明。

推荐诊断流程：

1. 在AAS图表右侧的类别下拉框中，首先选择 Waits（等待事件）维度。

2. 观察图表中颜色占比最高的区域，判断核心瓶颈类型：

   • Lock.tuple：行级锁争用，通常由并发更新/删除同一行数据引起。

   • LWLock.LockManager：轻量级锁争用，通常与高并发下的内部数据结构访问有关。

   • Client.ClientRead：客户端读取缓慢，可能是网络延迟或客户端处理慢。

   • CPU：CPU消耗过高，瓶颈在于计算资源。

   • LWLockBuffContent：内存页面锁争用，通常由热点数据页的高并发访问引起。

   

步骤三：追溯问题源头

确定瓶颈类型后，利用页面下方的Top N列表，精确定位导致问题的具体来源。

推荐追溯流程：

1. 切换至Top SQL列表，找到“按照SQL划分的负载(AAS)”最高的SQL语句。

2. 切换至Top Users和Top Hosts列表，确认执行该SQL的数据库用户和客户端IP。

3. （可选）切换至Top Waits列表，交叉验证步骤二识别的瓶颈类型是否吻合。

故障现象

监控显示从某时刻开始，慢SQL数量急剧上升，应用响应时间显著恶化。

数据库实例配置

• 数据库类型：PostgreSQL17.0。

• 实例规格：独享规格。

• 规格代码：pg.x2.2xlarge.2c。

• CPU：16 核。

• 内存：32G。

诊断分析

步骤1：性能指标趋势分析

检查关键性能指标趋势图，发现00:34时刻活跃会话数从正常的十几个大幅上升至1100+，超过PostgreSQL实例的合理并发处理能力。

步骤2：等待事件分析

通过平均活跃会话（AAS）图表的等待事件分布，识别出主要瓶颈集中在：

• Lock/transactionid：事务ID锁等待，通常由长事务或死锁引起。

• Lock/tuple：行级锁等待，表明存在严重的并发写入冲突。

活跃会话数远超16核CPU处理的基准线数值，确认系统处于严重的锁争用状态。

步骤3：SQL语句分析

Top SQL排行显示，前两个查询分别有220和119个会话在等待锁资源释放，这些SQL成为整个锁等待链的关键节点。

步骤4：来源追溯

结合Top Hosts和Top Databases数据，锁定问题源头：

• 异常客户端：140.205.XXX.XXX

• 目标数据库：perf_test

根因分析

故障类型：锁争用雪崩

技术原理：

• 触发原因：客户端对perf_test数据库发起高并发DML操作，可能涉及热点行更新或大事务处理。

• 失控机制：PostgreSQL的锁管理机制中，当多个事务竞争相同资源时，后续事务将进入等待队列。由于缺乏连接数限制和锁等待超时控制，新连接持续涌入，形成锁等待的恶性循环。

解决方案

即时措施

1. 限制异常客户端IP的连接数

   ALTER ROLE target_user CONNECTION LIMIT 10;   -- target_user:数据库用户名

2. 终止长时间等待的会话

   -- 先查看要终止的会话详情
   SELECT 
       pid,                                    -- 进程ID（会话标识）
       usename,                                -- 数据库用户名
       state,                                  -- 会话状态（active/idle等）
       wait_event,                             -- 等待事件具体类型
       now() - query_start AS query_duration,  -- 当前查询已执行时长
       left(query, 50) AS query_preview        -- SQL语句预览（前50字符）
   FROM pg_stat_activity 
   WHERE datname = 'perf_test'                 -- 限定数据库名称
     AND client_addr = '140.205.XXX.XXX'       -- 限定客户端IP地址
     AND state = 'active'                      -- 仅查询活跃状态的会话
     AND wait_event_type = 'Lock'              -- 仅查询正在等待锁的会话
     AND pid <> pg_backend_pid()               -- 排除当前执行此查询的会话（避免自杀）
     AND now() - query_start > interval '5 minutes';  -- 查询执行时长超过5分钟
     
   -- pg_terminate_backend会立即终止目标会话，可能导致事务回滚。
   -- 在生产环境中执行前，请务必确认目标会话可以被安全终止。
   SELECT pg_terminate_backend(pid) 
   FROM pg_stat_activity 
   WHERE datname = 'perf_test'
     AND client_addr = '140.205.XXX.XXX'
     AND state = 'active' 
     AND wait_event_type = 'Lock'
     AND pid <> pg_backend_pid()
     AND now() - query_start > interval '5 minutes';
   
   -- 确认目标会话是否已清理
   SELECT pid, usename, state, query 
   FROM pg_stat_activity 
   WHERE datname = 'perf_test'
     AND client_addr = '140.205.XXX.XXX';    

长期优化

1. 连接池配置：部署PgBouncer等连接池，控制最大并发连接数。

2. 超时参数调优

   -- 设置锁等待超时
   ALTER DATABASE perf_test SET lock_timeout = '30s';
   -- 设置语句执行超时
   ALTER DATABASE perf_test SET statement_timeout = '60s';

3. 应用层优化：

   • 减小事务粒度，避免长事务。

   • 使用乐观锁或分布式锁机制处理热点数据。

   • 实施读写分离，将只读查询分流至从库。

4. 监控告警：配置活跃连接数和锁等待时间的监控阈值，实现故障预警。

1. 关键性能指标解读

2. 理解AAS（平均活跃会话）图表

平均活跃会话（Average Active Session, AAS） 是性能洞察的核心分析图表，它以堆叠面积图的形式展示了数据库负载的构成。

• 横轴：时间线（精确到秒级，如13:32:05至13:50:05）。

• 纵轴：活跃会话数（数值越高，负载越大）。

• 颜色分层：在不同的维度下，不同颜色代表不同的 item。比如在等待事件维度下，不同颜色表示不同的等待事件类型，在 Host维度下不同的颜色表示不同的客户端。

• 基准线：图表中标注的"CpuCore: N"表示实例的CPU核心数，当AAS超过此基准线时，表明数据库负载已超出CPU处理能力。

  

• 分析维度：不同分析维度及功能说明如下表所示。

  分析维度	功能说明
  SQL	按SQL语句分类负载（默认视图），识别哪些SQL占用了最多的会话资源。
  Waits	按等待事件类型分类（如Lock、IO、LWLock等），是诊断瓶颈类型的关键维度。
  Application	按应用程序分类，区分不同应用系统或服务模块对数据库的影响。
  Host	按客户端主机IP分类，识别哪些服务器或客户端产生了最高的数据库负载。
  Session type	按会话类型分类，判断负载来自业务请求还是数据库内部的维护操作。
  User	按数据库用户分类，快速定位是哪个业务账号造成的压力。

3. 多维分析列表说明

位于页面下方的多维分析列表，用于从不同维度排序，展示Top N的负载贡献者。