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命中率低需要调整

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

posted @ 2023-09-18 16:14  KINGBASE研究院  阅读(373)  评论(0编辑  收藏  举报