kingbaseES 优化之数据库瓶颈排查

针对数据库的性能瓶颈排查方法分为两个层次1、实例级别性能问题排查 2、语句级别性能问题排查

实例级别

实例级别性能问题排查用来分析数据库实例整体是否存在性能瓶颈，然后根据排除出的疑似问题进行实例级别参数的优化。

使用场景包括

1、压测场景下数据库整体优化

2、上线之前数据库整体调优

3、业务整体响应缓慢情况下问题排查 等

排查手段

KWR报告

KWR报告能够从整体上对数据库的健康状况进行分析，包括系统负载、等待时间、IO，内存等使用情况、top SQL等正常情况下通过KWR报告就可以对数据库整体健康状况有一个整体认知，进而指定相应调优手段

生成步骤：

\dx

Create extension sys_kwr;

建议配置参数修改之后reload 即可，无需重启数据库

track_sql = on

track_instance = on -- KWR 1.3 新增参数

track_wait_timing = on  -- 默认开启

track_counts = on  --默认开启

track_io_timing = on

track_functions = 'all'

sys_stat_statements.track = 'top'

生成快照

CREATE EXTENSION sys_kwr;

SELECT * FROM perf.create_snapshot(); -- 获得快照 1

CREATE TABLE IF NOT EXISTS t1(id int); -- 创建一个示例表

SELECT count(*) FROM t1; -- 执行一些 SQL

SELECT * FROM perf.create_snapshot(); -- 获得快照 2

SELECT * FROM perf.kwr_report(1,2); -- 生成 TEXT 版本报告

SELECT * FROM perf.kwr_report(1,2, 'html'); -- 生成 HTML 版报告

-- 生成的 KWR 报告会自动保存到 DATA 目录下的 sys_log 子目录下

KSH

sys_ksh 以每秒采样的方式进行会话和数据收集，并将采集数据放入内存的 Ringbuf 队列中 对资源消耗大建议采用临时开启方式。相较于 KWR 包括，KSH的收集频率更快，产生内容更多，所以主要是在业务相应缓慢的时间段内收集，收集完成尽快关闭。

旧版本需要单独安装sys_ksh扩展， 新版本已经集成到sys_kwr 中

V8R6B24版本使用方法

Create extension sys_kwr;

sys_kwr.collect_ksh  设置 ksh=on 需要reload不需要重启

保存于内存 Ringbuf 的数据可以通过视图 perf.session_history 查看：

SELECT * FROM perf.session_history;

其中保存于数据库的历史数据可以通过视图 perf.ksh_history 查看：

SELECT * FROM perf.ksh_history;

生成的报告可以通过 perf.ksh_report 查看：

SELECT perf.ksh_report(start_ts, duration, slot_width, write_to_file);

KDDM

KDDM 是 KingbaseES 性能自动诊断和建议的报告。它基于 KWR 快照采集的性能指标和数据库时间模型（DB Time），自动分析等待事件、IO、网络、内存和 SQL 执行时间等，给出一系列性能优化建议。通过 KDDM 报告， 能够实现数据库性能的快速调优。

CREATE EXTENSION sys_kwr;

SELECT * FROM perf.create_snapshot();

INSERT INTO t1 SELECT generate_series(1, 1000000);

SELECT * FROM perf.create_snapshot();

SELECT * FROM perf.kddm_report(1,2);

--生成到指定位置

SELECT * FROM perf.kddm_report_to_file(1, 2, '/home/test/kddm_1_2.txt');

--生成指定sql的诊断报告

SELECT * FROM perf.kddm_sql_report(1, 2, 5473583404117387630);

KDDM相对于 KWR的优势在于，针对一些性能问题它可以给出比较合理的优化建议。

KWR DIFF

KWR 报告是 Diff 报告的基础，在数据库运行过程中，通常在业务的高峰期和低谷期，或者在参数调整之后， 数据库的性能指标都会发生变化，那么分析这种变化的根因对于我们分析数据库性能，进行优化调整是非常必要的。

Diff 报告的作用就是分析两个 KWR 报告之间的差异，找出性能变化的原因或分析性能优化的效果

CREATE EXTENSION sys_kwr;

SELECT * FROM perf.create_snapshot();

CREATE TABLE t1(a int);

INSERT INTO t1 SELECT generate_series(1, 1000000);

SELECT * FROM perf.create_snapshot();

INSERT INTO t1 SELECT generate_series(1, 1000000);

SELECT * FROM perf.create_snapshot();

INSERT INTO t1 SELECT generate_series(1, 1000000);

SELECT * FROM perf.create_snapshot();

SELECT * FROM perf.kwr_diff_report_to_file(1, 2, 3, 4,'/home/test/kwr_diff_rpt_00.html');

其中：

snap_1: 生成第一份 KWR 报告的起始快照 ID

snap_2: 生成第一份 KWR 报告的结束快照 ID

snap_3: 生成第二份 KWR 报告的起始快照 ID

snap_4: 生成第二份 KWR 报告的结束快照 ID

Kbbadger

可以分析大型的日志文件。当日志文件足够长时，kbbadger 可以自动检测日志文件的格式（syslog，stderr，csvlog 或 jsonlog）。 由 kbbadger 生成的所有图表都是可缩放的并且可单独下载为 PNG 文件。另外，在生成的报告中 SQL 查询将突 出显示

相关参数要求

log_min_duration_statement = 0  --需要reload

不要开启  log_statement 参数  --默认关闭

lc_messages='en_US.UTF-8'  -必须是英文，否则无法解析

常见使用语句

kbbadger /var/log/kingbase.log

kbbadger /var/log/kingbase.log.2.gz /var/log/kingbase.log.1.gz  /var/log/kingbase.log kbbadger

/var/log/kingbase/kingbase-2012-05-*

kbbadger --exclude-query="^(COPY|COMMIT)" /var/log/kingbase.log

kbbadger -b "2012-06-25 10:56:11" -e "2012-06-25 10:59:11"  /var/log/kingbase.log

cat /var/log/kingbase.log | kbbadger -

kbbadger --prefix '%t [%p]: user=%u,db=%d,client=%h' /sys_log/kingbase-2012-08-21*

kbbadger --prefix '%m %u@%d %p %r %a : ' /sys_log/kingbase.log

# Log line prefix with syslog log output

kbbadger --prefix 'user=%u,db=%d,client=%h,appname=%a' /sys_log/kingbase-2012-08-21*

# Use my 8 CPUs to parse my 10GB file faster, much faster

kbbadger -j 8 /sys_log/kingbase-10.1-main.log

相关视图

sys_stat_statements 视图

在系统资源排查后发现是数据库相关性能使用问题，首先可以通过sys_stat_statements 查看数据库sql语句执行情况，发现有问题语句并进行优化

该视图可以查询内容包括

1、语句内容

2、语句执行次数

3、语句解析次数和时间

3、shared_buffer 使用情况是否用到了磁盘read 还是用到了 shared _buffer hit

4、temp_buffer ，work_me,maintance_men 命中情况  通过local字段排查

sys_stat_activity 视图

查看目前连接数据库的连接信息，以及这些连接信息目前的状态比如

1、是否有等待事件

2、锁信息

3、连接方式和地址

4、连接开始时间

5、事务开始时间

6、查询语句开始时间

7、查询语句

IO分析试图 sys_stdio_user_tables和 sys_stdio_user_indexes内容包含

1、表中数据读盘或者内存命中的数量

2、表中索引读盘或者内存命中的数量

3、toast表读盘或者内存命中的数量

lock信息

sys_locks

语句级别

针对单独的一条语句或一次跑批语句进行性能能瓶颈排查，主要还是依赖于执行计划根据执行计划进行语句分析

KingbaseES 中 explain 命令来查看执行计划时最常用的方式。其命令格式如下：

explain [option] statement

其中 option 为可选项，可以是以下 5 种情况的组合：

• analyze：执行命令并显示执行事件，默认 false

• verbose：显示附加信息，比如计划树中每个节点输出的字段名等，默认 false

• costs：显示执行计划的成本，默认 true

• buffers：显示缓冲区的使用信息，包括共享快、本地块和临时读写块，默认 false，前置条件是 analyze

format：指定执行计划的输出格式，支持：TEXT、XML、JSON 或者 YAML，默认是 text

生成执行计划之后我们主要阅读内容包括

执行计划里每个节点主要内容包括：

• 执行动作，及其附加条件，比如索引扫描，索引条件等

• 估算成本：启动 cost、总体 cost • 估计返回的行数和平均宽度

• 如果开启了 Analyze 选项，还会返回：

– 实际成本：启动 cost、总体 cost – 实际返回的行数，节点循环执行次数

我们分析的思路首先为性能点， 先看总体cost然后看看各个步骤的cost，找到占比最高的步骤确认为性能点进行分析，

然后分析步骤正在做的内容，围绕三个点分析

1、scan方式

2、连接方式

3、排序等其他控制操作耗时。

通过分析执行计划可以定位到sql语句的问题点

比如：

执行计划查看 Sort Method: external merge Disk: 99648kB 说明用到了磁盘排序 work_mem需要调整

执行计划中预估和实际执行评估rows差异较大说明统计信息不准确

执行计划中扫描过程更多的用到了物理读，说明buffer命中率低需要调整

执行计划中出现了全表扫描就需要分析全表扫描是否合理等。