【GaussDB】GaussDB性能调优分析思路

1 业务现象

GaussDB的总体性能调优思路为性能瓶颈点分析、关键参数调整以及SQL调优。在调优过程中，通过系统资源、吞吐量、负载等因素来帮助定位和分析性能问题，使系统性能达到可接受的范围。

2 技术背景

在明确调优范围 后需要对性能做一个整体问题诊断，分析数据库服务器资源 消耗情况，再看引发资源瓶颈不优的 S QL语句。

不优的S QL 语句主要优化的场景一般有两类：单条SQL性能优化和并发SQL的性能优化。其中并发场景的性能优化是要基于单条SQL优化已经完成的前提下进行的！下面详细说明一下相关优化思路。

3 调优思路

3.1 单条SQL的性能优化（简单SQL+复杂SQL）：

3.1.1 对于单表查询的SQL

1）选择正确的分布列，对于点查SQL选where条件过滤性较好重复值较少的列作为分布列，让数据分布均匀；

2）在过滤性较好的列上创建索引 ，确保点查结果集较小的点查SQL使用上索引；

3）对于group by类大数据量的分组统计，可打开SMP并行和开启向量化引擎来提升性能；

同时，需要合理判断SQL执行耗时是否正常，如单表点查SQL一般explain analyze耗时在0.5ms左右 ，explain查看计划有bypass关键字，此类SQL最优的计划是下推至单dn后走索引查询。

3.1.2 对于多表关联的SQL

1）选择合适的分布列 ，如果一个SQL的计划中出现streaming关键字 ，则很有可能表的分布 列选择 不正确，需要进行分布列调整，分布列的选择原则是DN的各节点数据均匀分布。

2）**选择合适的分布方式，**在分布表表的分布列不能完全避免stream的情况下，可以考虑将某些表建成复制表，分布方式的选择原则：

复制表（Replication）方式将表中的全量数据在集群的每一个DN实例上保留一份。主要适用于记录集较小的表。这种存储方式的优点是每个DN上都有该表的全量数据，在join操作中可以避免数据重分布操作，从而减小网络开销，同时减少了plan segment(每个plan segment都会起对应的线程)；缺点是每个DN都保留了表的完整数据，造成数据的冗余。一般情况下只有较小的维度表才会定义为Replication表。
哈希（Hash）表将表中某一个或几个字段进行hash运算后，生成对应的hash值，根据DN实例与哈希值的映射关系获得该元组的目标存储位置。对于Hash分布表，在读/写数据时可以利用各个节点的I/O资源，大大提升表的读/写速度。一般情况下大表定义为Hash表。
范围（Range）和列表（List）分布是由用户自定义的分布策略，根据分布列的取值落入满足一定范围或者具体值的对应目标DN，这两种分布方式便于用户灵活地进行数据管理，但对用户本身的数据抽象能力有一定的要求。

例：a.c1 =b.c1 and a.c2=c.c2，如果abc三表都是分布表，则必然出现stream情况，此时为了避免streaming，需要判断a表和c表哪张表更小，将较小的那张表建成复制表，比如c表较小，则此时的分布列选择为a以c1列为分布列，b以c1为分布列，c建成broadcast表。

3）创建合适的索引

对于最终结果集较小（1/10/100）的SQL：此类SQL一般是有某张表有where条件等值过滤，过滤后结果集很小 ，然后再去跟其他表关联，这种情况下的最优计划 是等值条件过滤的列有索引是通过索引进行的快速过滤 ，然后与之关联的表关联列上都有索引，通过层层索引过滤 后得到最终结果。此类SQL的执行计划中一般都是index scan和 nestloop之类的关键字，如果出现seq scan、hash join等关键字很有可能计划不是最优，此时需要进行调整。

4）对于有较大数据需要计算的SQL，如整表无等值条件关联、统计分析、排序的SQL，需要打开SMP并行和开启向量化引擎

5）以上都分析好以后，还需要关注表的关联顺序是否正确， 原则是哪两个表关联能先过滤较多的数据就哪两个表先关联。

3.1.3 创建索引优化性能：

1）调大内存参数，set maintenance_work_mem = '8GB';（可根据实际情况调整值大小）

2）打开表级索引并行创建，alter table test_t1 set (parallel_workers=8);（可根据实际情况调整值大小）

3）创建索引，create index ......

4）关闭并行，alter table test_t1 reset parallel_workers;

3.2 并发SQL性能优化

1）先按照上述3.1节描述的将单条SQL性能优化好 ，注：并发量较大 的情况下复杂SQL也无需开SMP并行，视具体情况分析而定；

2）根据硬件资源和数据库活跃连接数判断数据库是否到瓶颈 ，经常碰到并发压力并未到数据库端的情况，实际瓶颈在应用压测机客户端，常碰到的现象有：数据库端CPU、IO压力很低不足50% ，数据库活跃连接很少远低于实际并发数，如1000并发时数据库端活跃连接只有百来个甚至更少，此时需要先解决客户端瓶颈问题；

3）确定瓶颈在数据以后，再根据等待事件、WDR报告等分析具体瓶颈，针对具体情况调整相应内存、IO、计划缓存等相关的参数。

详细的分析思维导图和相关命令可参考整体性能和单语句性能问题

整体性能

单语句性能

3.3 对应的一些定位sql语句如下

定位sql语句需要开启相关GUC参数：

sql 复制代码

gs_guc reload -Z coordinator -Z datanode  -N all -I all -c "track_activities='on'"
gs_guc reload -Z coordinator -Z datanode  -N all -I all -c "enable_resource_track='on'"
gs_guc reload -Z coordinator -Z datanode  -N all -I all -c "enable_instr_track_wait = on"
gs_guc reload -Z coordinator -Z datanode  -N all -I all -c "track_sql_count = on"

线程池中工作线程及会话的状态信息

sql 复制代码

select node_name,session_info from dbe_perf.global_threadpool_status order by 1;

查询本节点活跃会话状态及等待事件

sql 复制代码

select sample_time,substring(unique_query,0,100),application_name,wait_status 
from dbe_perf.local_active_session where wait_status not in (''none'',''wait cmd'') 
order by start_time desc;

查询本节点活跃会话等待事件统计

sql 复制代码

select wait_status,count(*) from dbe_perf.local_active_session group by wait_status order by 2 desc;

查询耗时sql

sql 复制代码

select query from dbe_perf.statement where user_name!='omm' order by cpu_time desc;

查询采样SQL平均耗时及最大耗时

sql 复制代码

select node_name,unique_sql_id,substring(query,0,100),total_elapse_time/n_calls/1000 as single_time_consumption,max_elapse_time
 from dbe_perf.summary_statement where n_calls>1 
and max_elapse_time > 1000000;

查询会话sql个数抓取：

sql 复制代码

select query,count(query) from pg_stat_activity where state != 'idle' group by query;

指定节点查询特定sql历史等待事件

sql 复制代码

select wait_status, count(*) from gs_asp where unique_query_id=xxxx group by wait_status;
select wait_status, application_name, count(*) from gs_asp where unique_query_id=xxxx group by wait_status,application_name';

清空系统视图：

sql 复制代码

select reset_unique_sql('GLOBAL','ALL',0);

查询连接数是否均匀：

sql 复制代码

select coorname,count(*) from pgxc_stat_activity where query like '%xxxx%' group by coorname;

4 简单总结

在明确调优范围后，需要分析服务器资源信息以及资源使用情况，再分析不优的SQL语句，使用对应的一些定位sql语句找到性能问题。

转载：华为云论坛