@

• 问题描述
• 问题现象
• 告警
• 业务影响
• 原因分析
• 分析步骤
• 分析定位方法
  • 步骤一
  • 步骤二
  • 步骤三
  • 步骤四
    • CPU满
    • I/O满或者I/O异常
    • 内存满
    • 网络异常
  • 步骤五
    • 并发问题
    • 数据库配置问题
    • 异常等待事件
    • 长时间性能下降
    • 短时性能抖动
    • 不优SQL

问题描述

整体性能慢。不满足客户作业对时延要求或者不满足客户预期。

问题现象

业务反馈业务接口时延高；或者数据库P80/P95等指标升高；有可能会出现大量慢SQL。

告警

• 业务侧相关接口时延、成功率等告警。
• 数据库内核P80/P95相关告警。

业务影响

业务时延受损，或者业务在预期时间内无法执行完成。

原因分析

在处理整体性能慢问题时，在投入分析系统数据之前，有可能的情况下建议先去和客户沟通，了解相关问题背景，如：客户的预期或者目标、是否有业务变更、业务作业类型等，从而明确性能调优的前提和目标。
整体性能慢，首先需要找到瓶颈点，准确的瓶颈点将会对性能调优指明方向。有可能优化掉一个瓶颈点，对性能不一定有百分百的效果，同时可能又会转移到另外一个瓶颈点，优化是一个不断迭代的过程，比较耗时。
整体性能慢原因可能有多种，常见有如下几种：

1. 业务侧原因。
2. 系统资源不足。
3. 不优数据库内核资源使用。
4. 并发问题。
5. 数据库配置不优。
6. 不优SQL。

分析步骤

分析定位方法

步骤一

了解整体性能慢背景，如：客户预期、业务类型、近期业务变化、系统是否发生变化等等。

步骤二

明确压力是否传递至内核，或者说瓶颈点是否在内核侧。
可以查询数据库所在主机的CPU使用率、数据库内核相关视图、或者OPS上相关指标，明确可能是业务侧问题还是数据库侧问题，通过下面排查项可以查看是否有相关的压力传递至数据库内核。

• 数据库相关视图：
  • pg_stat_activity/pgxc_stat_activity（track_activities=on）：关注state状态为非idle的会话。
  • dbe_perf.local_threadpool_status/dbe_perf.global_threadpool_status：关注session_info字段。
• OPS上实例监控相关指标：
  • CPU占用率。
  • 活跃会话数量。

如果说数据库活跃会话极少，数据库的吞吐大概率是无法上来，参考步骤3；否则参考步骤4。

步骤三

如果数据库侧未明显感知到业务压力，或者压力不够大，资源消耗极低，比如：CPU不足10%、活跃会话数量个位数，则建议业务侧进行相关排查，比较常见的情况可能有如下原因：

• 应用服务器资源耗尽，CPU/IO/内存不足。
• 应用服务器和内核网络时延过高。
• 应用服务器处理查询结果慢，导致事务内SQL语句下发至内核慢。

步骤四

排查数据库所在系统资源是否有异常。

CPU满

可通过OPS CPU使用率或者操作系统top命令查看CPU使用率；也可以使用sar命令，查看历史的CPU使用率。

$ cd /var/log/sa 
$ sar -f sa 
12:00:01 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle 
12:10:01 AM     all     41.40      0.00     10.14      0.05      0.00     48.42 
12:20:01 AM     all     41.37      0.00     10.15      0.05      0.00     48.42 
12:30:01 AM     all     41.40      0.00     10.18      0.06      0.00     48.36 
12:40:01 AM     all     41.40      0.00     10.16      0.05      0.00     48.40 
12:50:01 AM     all     41.31      0.00     10.11      0.03      0.00     48.55 
01:00:01 AM     all     41.40      0.00     10.13      0.02      0.00     48.44

找到CPU使用率高的进程，如果是数据库导致的CPU异常，通常预期是gaussdb进程占用较高。

$ top 
top - xxxxxx up 44 days,  1:06,  0 users,  load average: 34.91, 35.33, 35.14 
Tasks: 641 total,  10 running, 631 sleeping,   0 stopped,   0 zombie 
%Cpu(s): 41.3 us, 10.1 sy,  0.0 ni, 48.6 id,  0.0 wa,  0.0 hi,  0.1 si,  0.0 st 
KiB Mem : 19748899+total, 14801132 free,  8637000 used, 17405084+buff/cache 
KiB Swap:  4194300 total,        0 free,  4194300 used. 10027731+avail Mem 
 
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND 
10678 Ruby      20   0   54.8g  38.2g  34.6g S  1398 20.3 126085:50 gaussdb 
58736 Ruby      20   0 4901420  53220   6520 S  22.8  0.0   2624:15 cm_agent 
57648 Ruby      20   0   12.9g  90624  10168 S  10.6  0.0   1208:55 etcd

如果为某段时间内CPU高，则可比较正常时间段和异常时间段的WDR报告中Top SQL order by CPU部分，可参考后续的文章WDR报告分析。

如果CPU一直较高，方法一：可直接使用WDR报告中SQL ordered by CPU Time部分，尝试优化分析相关语句，可参考后续文章WDR报告分析；方法二：按照CPU高进行分析。
如果短时间CPU异常，按照CPU高进行分析。
如果仍然无法分析出CPU消耗原因，可以生成异常时间段内的火焰图，找到内核代码函数的瓶颈点，可参考后续文章火焰图分析。

I/O满或者I/O异常

表现为iostat内%util满、或者r_await较高（一般大于3ms）、或者w_await较高（一般大于3ms）。
如果上述I/O的指标存在异常，比如I/O读写量上不去、时延较高，可联系操作系统相关同事分析，可能的原因有：

1. 硬盘cache/raid写策略配置问题。
2. 磁盘带宽被限流（OBS本身有流控）。

如果本身I/O量大，可以使用pidstat/iotop来分析I/O量消耗的线程。

1. pidstat -dt -p gaussdb进程号
2. iotop

通常是TPLworker线程消耗的I/O读写量异常，代表用户SQL消耗I/O多，其中TID表示内核线程的LWTID，可通过如下过程找到对应的在运行SQL语句：

1. pidstat/iotop内目标TID。
2. 通过查询pg_thread_wait_status视图的lwtid为上一步内的TID，获取对应的tid和sessionid。
3. 查询pg_stat_activity视图内记录满足pid/sessionid为上一步内的tid/sessionid,即可找到造成I/O高的session信息，包括具体的语句。

接下来就可以单独去优化相关Query，减少I/O量，可参考单SQL性能慢分析。
另外，可以通过WDR报告内SQL ordered by Physical Reads部分识别对应时间段内造成I/O读取量较大的Query，可参考后续文章WDR报告分析。

对于I/O量一直很大，如果是用户语句导致，也可参照IO高进行处理。

内存满

内存不足有可能会导致程序执行缓慢。
首先需要找到内存占用异常的进程，此处仅考虑gaussdb内存占用异常情况，其它进程不具有代表性意义，此处不过多描述。
gaussdb进程内存占用异常，可参照内存高进行处理。

网络异常

网络异常常见的有几种情况:

1. 网络不通：这种场景在业务刚上线的时候，有时候会遇到，表现为数据库无压力，或者无某些业务服务器的连接，可查询pg_stat_activity相关视图内在线client连接IP信息。
2. 网络时延高：通常表现为业务侧数据反馈时延慢，内核侧时延短，通过使用ping命令即可验证猜测。
3. 网络带宽满：这种场景可能会比较少，一般网络带宽比较大，如果遇到这种情况可以查看ops和应用侧相关网络流量曲线，通常随着压力增长网络流量会上升，有时会遇到网络压力不再上涨，而且未达到网卡理论上限，此时可找网络同事分析相关异常点。

步骤五

排查数据库内核是否使用不优。

并发问题

此问题主要由于并发更新，产生的锁等待，从而导致业务时延上涨、TPS下降、或者线程池满等。

数据库配置问题

正常情况下，客户环境上面的GUC配置是默认较优的，一般不需要特别调整。但某一些情况下，可能未使用默认配置或者客户环境有些微调的地方。常见的可能情况有：

1. shared_buffers配置过小，导致buffer淘汰频繁。
2. 排序等算子可使用的work_mem过小，导致异常下盘过多，建议根据业务情况适当优化。
3. 线程池worker参数thread_pool_attr设置过小，导致业务排队。

异常等待事件

数据库内等待事件分为 STATUS、LWLOCK_EVENT、LOCK_EVENT、IO_EVENT。
识别异常等待事件通常是非常有效的整体性能慢的诊断手段详细可参考1.2.7 整体性能慢-等待事件分析。

长时间性能下降

长时间性能下降通常的场景，通常是指某段时间(小时级)性能抖动，比如: 过去8:00-9:00性能正常，但10:00-11:11性能出现较大的性能抖动，这种场景，可以比较两段时间内WDR报告，排查报告内差异点，可排查Top SQL、Top Wait Events、Load Profile、Cache/IO Stats、Object Stats等。

短时性能抖动

当前WDR快照默认为一小时一次，正常对于小时级的性能抖动，WDR足够覆盖这种场景。但当出现秒级性能抖动，因为性能视图多为累积值，WDR通常无法体现。

不优SQL

当前数据库内核默认是开启线程池的，由于某些或者某个不优SQL慢，导致业务整体性能差，或者占满整个内核线程池，从而可能会引发更加严重的业务阻塞。
此处仅描述不优SQL识别，对于不优SQL的调优，可参考1.2.1 单SQL性能慢分析，通常分为以下几种情况：

• 当前正在执行的SQL大批量慢：这种场景比较常见，一般可以通过pg_stat_activity查询获取相关SQL，可结合当前语句执行时间长短识别，如：(now() - query_start) as duration。
• 发现大量慢SQL：通过OPS慢SQL指标可发现慢SQL数量短时间增加，并结合OPS的P80/P95、TPS、QPS等指标识别慢语句对整体时延的影响，如果明确相关，可查询慢语句表statement_history，找到目标慢语句，此处注意要切到postgres库。
• 过去某段时间业务反馈慢：
  1. 可以使用相应时间段的WDR，分析异常TOP SQL，可参考1.2.4 WDR报告分析。
  2. 另外通过active session profile(ASP)，分析过去运行慢的SQL。