人大金仓KingbaseES KWR中等待事件分析案例

背景

昨天有现场同事碰到了一个现象，一条简单的update语句运行缓慢。单独运行没有问题，在特定时间运行就会非常缓慢，怀疑是业务系统特殊逻辑导致数据库有阻塞引发的update语句慢的现象。故此现场同事收集了对应时间的kwr报告。

报告分析

首先从dbtime看数据库并没有达到满负荷，依然有上升空间。

我们看到blocks读和写都很高，平均每秒读4MB左右，同时tuple return20亿左右，这也为下面的分析埋下伏笔，看来和io脱不了干系。

 等待事件是我们必须关注的，很明显等待事件BufFileRead占了dbtime21.9%。

 这时候我们先停下来，先把等待事件BufFileRead/BufFileWrite 好好看一下。这个两个等待事件表示当，内存空间不够时（work_mem），需要将超过内存的内容写入到临时文件。当写临时文件时，等待BufFileWrite，当读取时，等待 BufFileRead

这个等待事件含义从临时文件中读取数据到指定buffer。这个等待事件是创建临时文件时产生，这就无疑和排序操作有关。所以能想到相关联的两个参数是work_mem and maintenance_work_mem，稍后我们可以从kwr中看到这两个参数的设置。

当查询需要比work_mem参数设置值更多的memory时候，通常为这些情况：

• Hash joins
• ORDER BY clause
• GROUP BY clause
• DISTINCT
• Window functions
• CREATE TABLE AS SELECT
• Materialized view refresh

避免等待事件方法：

1，避免笛卡尔积，没有创建索引等。

2，如果重复行很多，避免使用distinct，开销很大。

3，增加work_mem内存大小，注意这个参数针对单个会话内存而言，小心并发会消耗大量内存。并发数*work_mem。同时注意不管内存增加多大，保证即使业务高峰也要给操作系统留够充足内存。

4，如果有必要 尽量不要设置过大的max_connections，保证并发数量。

分析到这里看起来和临时文件有关系。接下来我们继续看kwr报告。

从IO profile这里看出temp block 读写量巨大。由此可见报告开头的IO量消耗在了这里。

前台进程基本都等待在IO上

这几个sql明显消耗很长时间，建议看一下执行计划是否有不合理的地方。

消耗IO时间长的语句需要关注下

看来导致等待事件的源头找到了 ，是这个排名第一的占用temp blocks的语句

总结

通过以上分析，数据库可以调整的地方为增加work_mem，当前设置10MB。

可以调整log_temp_files以避免产生大量临时文件。

关注topsql语句的性能，查看topsql执行计划。抓出消耗temp blocks最多的语句。总之需要避免产生如此多的临时文件，规避IO引起的性能问题.