浅谈GaussDB(DWS)中创建性能基线的几个原则

当一个数据库系统承载的业务复杂、运行负载较高时，其性能波动往往较大，经常需要优化诊断，创建简单可用且有效的性能基线则十分有必要。作为参照标准，性能基线必须能够反映在特定环境和条件下，数据库系统能够达到的最优性能，通过提供持续的可观测的量化指标，衡量数据库的运行状态和健康程度。

目前大多数数据库使用并发能力、TPS或者QPS作为性能基线，这几个指标虽然在一定程度上能够反映数据库的性能压力情况，但仍然不够准确、全面。在脱离了响应时间标准的情况下，单纯的并发量，只能反映系统承载压力，不能反映系统的性能表现。并发+响应时间=TPS，确实可以反映出系统的性能表现，但考虑到事务的多样性和复杂性，TPS指标不具有普适价值。QPS是一个较好的性能基线指标，但更适合OLTP场景的系统，针对分布式的OLAP系统，在衡量并发、响应时间等因素的情况下，还需要关注各个计算节点之间的通信能力。

在我们的GaussDB(DWS)项目实践中，采用实际的业务语句作为性能探针，配置自动化脚本，每隔十分钟打印一次analyze执行计划。选择业务语句作为性能探针需要遵循以下几个原则：（1) 必须是select查询语句，且有简单的关联操作；（2）语句中涉及的表的数据量需要保持基本不变；（3）语句在集群最优性能下的查询时间一般10s以内为宜，最好不超过30s；（4）执行计划中需包含stream算子（gather、redistribute、broadcast）；（5）语句需要使用超级管理员用户执行（例如omm或者Ruby）。

我们以下面的性能探针语句的执行计划为例进行说明：

1、在很多局点，基于安全性和审计要求，生产环境往往不允许随意变动数据，包括创建、修改和删除操作，因此性能探针只能使用查询语句。考虑到GaussDB(DWS)是一个分布式架构的系统，其节点/实例之间的通信交互情况对集群性能影响较大，必须要在性能基线里面得到体现。因此性能探针语句还需要包含简单的关联操作，例如inner join、left join、exists等，确保语句在查询中数据能在各节点之间进行流动，以此来评估网络通信情况。上图的执行计划中，“Query Summary”部分可以查看DN建连的最小时间和最大时间。

2、由于性能基线指标在问题诊断时需要作为参考标准，在系统最优性能情况下其响应时间必须是稳定的。影响SQL语句查询时间变化的因素较多，在假设系统资源、参数配置等不变的情况下，保持语句中所有表的数据量基本不变在很大程度上能够确保语句的查询时间基本处于一个稳定水平。

上图的执行计划中可以对语句运行的各个环节启动时间和最长时间进行对比分析。Total Runtime为语句运行的总时间，采集该值绘制图表，通过曲线变化能够反映集群性能波动和业务运行情况。

3、为了不影响集群其他语句正常运行，不造成资源争抢，同时能够快速采集结果，性能探针语句执行时间不能太长，一般10s以内为宜，最好不超过30s。上图的语句正常运行时间为2s左右，在业务繁忙时间段，执行时间可能会增长到40s左右。

4、在GuassDB(DWS)中，各节点/实例之间数据交互是通过Stream算子实现的，评估节点之间网络通信情况可以参考执行计划中Stream算子的运行时间。在执行计划中，如果broadcast、redistribute、gather算子耗时较正常时较长，则可能存在通信瓶颈，部分或者某个节点出现了异常，如数据倾斜、I/O异常、网卡多队列丢失、硬件故障、CPU飙高、异常进程等，需要进一步分析诊断。

5、生产集群往往根据业务实际情况配置了资源池及并发策略，不同用户拥有不同的优先级及资源配额，如果使用普通用户运行性能探针语句，则可能会出现并发排队、资源不足的情况，此时性能探针返回的结果则不能真实反映数据库的性能状态和健康程度。因此必须使用超级管理员用户运行，使其不受全局并发、资源池并发策略限制。