GaussDB整体性能慢分析

问题描述

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

问题现象

业务反馈业务接口时延高；或者数据库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