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命中率低需要调整
执行计划中出现了全表扫描就需要分析全表扫描是否合理等。