1      调优概述鲲鹏性能分析工具是一款针对鲲鹏平台的性能调优工具，包含系统性能分析、Java性能分析和诊断调试分析三大功能。本调优实践使用的是系统性能分析，针对在虚拟机上部署的Redis性能不高问题，通过执行访存分析任务，找到性能瓶颈和问题点，并根据分析结果进行优化，从而实现Redis数据库性能的提高。2      组网环境表2-1服务器类型KVM虚拟机(基于TaiShan 200服务器(型号2280)部署)配置信息4U8G100GOSCentOS 7.6（内核：4.14.0-115.el7a.0.1.aarch64）应用Redis 5.0性能测试工具redis-benchmark（Redis自带工具）说明： 本实践环境配置信息只用作举例，在其他环境上相关操作类似。3      前提条件  服务器和操作系统正常运行。  目标环境（服务器）上3.T10版本工具已经安装完成，并正常运行。  目标环境（服务器）上已安装好数据库和性能测试工具。4      调优思路  启动Redis数据库服务，使用redis-benchmark工具对数据库进行加压测试。检查压测结果，发现性能指标不是很高。  重新运行压测，同时使用Hyper Tuner工具的访存分析，以整个系统作为采集分析对象创建任务，采样类型全部勾选，根据分析任务分析结果进行分析，根据已有的调优经验或手段进行调优。  重新运行压测工具，检查性能是否得到提升。5      调优过程5.1      执行压测  1.启动Redis数据库服务。        2.使用自带的压测工具在本地对数据库进行压力测试。压测参考命令如下图所示（没有指定特定的压测项，会对所有项进行压测），指定-c 50个并发，-n 10万个请求，-q 只打印最后结果。      3. 检查压测结果通过对压测结果的数据进行分析，发现性能并不是很高，没有达到预期的结果。根据Redis的特点是基于内存的数据库，使用系统性能分析工具的访存分析能力尝试对数据库性能进行分析，找出性能问题点。表5-1类型RPS（requests per second）PING_INLINE47915.67PING_BULK53022.27SET67069.08GET60606.06INCR62073.25LPUSH72463.77RPUSH69300.07LPOP68493.15RPOP70126.23SADD67294.75HSET71633.23SPOP61236.99LPUSH (needed to benchmark LRANGE)72992.70LRANGE_100 (first 100 elements)29859.66LRANGE_300 (first 300 elements)14432.10LRANGE_500 (first 450 elements)10914.65LRANGE_600 (first 600 elements)8775.78MSET (10 keys)72046.11 5.2     执行访存分析1.在后台使用相同的压测参数执行压测，同时在性能分析工具上创建访存分析任务，配置参数如下图所示，利用访存统计分析，检查系统缓存访问和DDR访问情况。 2.任务执行完成后检查任务结果。**在“总览”界面通过查看Core Cache Miss平均值，发现相关指标的值都比较高；而iCache Bandwidth和dCache Bandwidth平均值不是很高，与理论带宽有一定差距。**在“访存访问”页面，可以看到L1D和L2D的带宽也不是很高，对应的L1D命中率在0.98，L2D的命中率在0.82左右。**在“DDR访问”页面可以看到，DDR访问中存在较多的跨DIE访问，相对于本地访问次数的占比超过了50%。总览结果页面：访存访问结果页面：DDR访问结果页面：  3.通过以上访存分析结果，再根据当前服务器类型使用的是虚拟机。分析可能原因：部署的虚拟机的方式，在默认情况下不同虚拟机的vCPU可能运行在相同物理CPU核上，会造成CPU资源竞争，同一个虚拟机在不同时间也可能会运行在不同的物理核上，会造成cache miss的情况。另外也可能出现虚拟机内存访问出现跨die和跨片情况。针对以上情况，可进行的调优手段是，对虚拟机的vCPU进行绑核，绑到同一个NUMA节点上，同时可以将虚拟机内存访问绑到对应的NUMA节点上，可避免出现内存跨die和跨片情况。 5.3       性能优化1、检查虚拟机的配置文件。发现使用的是默认配置，配置文件里的确没有绑核和绑定内存访问的相关配置项。2.手动进行配置项修改，在宿主机上修改虚拟配置文件（命令：virsh edit 虚拟机domian）。在配置文件里配置<numatune>和<cputune>选项，配置项参考如下：  <cputune>    <vcpupin vcpu='0' cpuset='50'/>    <vcpupin vcpu='1' cpuset='51'/>    <vcpupin vcpu='2' cpuset='52'/>    <vcpupin vcpu='3' cpuset='53'/>    <emulatorpin cpuset='50-53'/>  </cputune>  <numatune>    <memory mode='strict' nodeset='1'/>  </numatune>将虚拟机的vCPU核绑到对应的物理机的50-53核上，这些物理核所在的NUMA节点为node1，因此将虚拟机的内存访问同时绑到node1这个节点上，模式采用“strict”严格从指定node上申请内存。修改后保存并退出。3、关掉虚拟机（命令：virsh shutdown 虚拟机domian），再重启虚拟机（命令：virsh start 虚拟机domian）。5.4     再次执行访存分析和压测 1.执行访存分析（同时运行压测），查看结果。总览结果界面：Core Cache Miss平均值，发现相关指标的值相比调优前有所降低；而iCache Bandwidth和dCache Bandwidth平均值有所提高。缓存访问结果页面：可以看到L1D带宽有所提高，对应的L1D命中率在0.98，L2D带宽和命中率略有下降，说明CPU cache使用集中在L1上。DDR访问结果页面：DDR访问中，跨片访问次数极低，读DDR跨DIE访问相对本地访问占比在15%，写DDR跨DIE访问也极低。  2.重新单独执行压测。表5-2类型RPS（requests per second）PING_INLINE65104.17PING_BULK62539.09SET71479.62GET65659.88INCR72046.11LPUSH77279.75RPUSH74906.37LPOP75872.54RPOP71839.09SADD71275.84HSET75872.54SPOP66800.27LPUSH (needed to benchmark LRANGE)77101.00LRANGE_100 (first 100 elements)30959.75LRANGE_300 (first 300 elements)14619.88LRANGE_500 (first 450 elements)11106.18LRANGE_600 (first 600 elements)8823.79MSET (10 keys)72833.21    通过测试的结果可以看到性能数据有所提升。  6. 实践结论1.性能结果对比表6-1类型RPS（requests per second）性能对比调优前调优后PING_INLINE47915.6765104.17+35.9%PING_BULK53022.2762539.09+17.9%SET67069.0871479.62+6.6%GET60606.0665659.88+8.3%INCR62073.2572046.11+16.1%LPUSH72463.7777279.75+6.6%RPUSH69300.0774906.37+8.1%LPOP68493.1575872.5410.1%RPOP70126.2371839.092.4%SADD67294.7571275.84+5.9%HSET71633.2375872.54+5.9%SPOP61236.9966800.27+9.1%LPUSH (needed to benchmark LRANGE)72992.7077101.00+5.6%LRANGE_100 (first 100 elements)29859.6630959.75+3.7%LRANGE_300 (first 300 elements)14432.1014619.88+1.3%LRANGE_500 (first 450 elements)10914.6511106.18+1.8%LRANGE_600 (first 600 elements)8775.788823.79+0.5%MSET (10 keys)72046.1172833.21+1.1%通过调优前后性能数据的对比，每一个压测指标项的性能都得到了不同程度的提升。整体性能的提升达到了+8.16%，说明优化的效果是比较明显的。   2.总结本次调试实践，主要是针对在虚拟机平台上利用Hyper Tuner系统性能分析工具的访存分析能力对Redis数据库性能不高问题的分析。根据分析结果发现的问题进行分析，并利用已有的相关调优经验实施调优，最终使性能得到了较大的提升。

1.调优概述使用鲲鹏性能分析工具（Hyper Tuner）中的热点函数分析及锁与等待分析功能对目标环境的多线程应用程序进行采样分析，找到性能瓶颈点，并根据分析结果进行优化修改，从而实现应用性能提升。2.环境要求本实践以TaiShan 200服务器（型号2280）+CentOS 7.6组网举例，Hyper Tuner在其他鲲鹏平台和操作系统上的操作类似。3.前提条件服务器和操作系统正常运行。PC端已经安装SSH远程登录工具。目标环境上HyperTuner工具已经安装完成，并正常运行。4.调优思路在进行调优之前，先用HyperTuner工具对目标环境的多线程应用程序进行采样分析。针对应用中的热点函数进行分析，通过相关函数实现进行优化。对优化后的应用再次进行热点函数分析及锁与等待分析，验证调优后的效果。5.调优过程现状分析函数实现的功能为多个线程对一个变量进行累加操作。执行热点函数分析可以看到实际的两个线程对应的功能函数fun2与main时钟周期占比很小，主要热点在glibc对应的互斥锁上面。执行锁与等待分析任务可以看到对应锁的调用情况，以及对应功能函数里的源码，对于变量num进行累加操作前后需要使用互斥锁，保证读个线程的操作均被执行到。但是应用的实际效率是很低的，过多的开销花费在了互斥锁的require和release上面。性能瓶颈分析和优化实际功能代码的执行速度很快，多线程使用锁的方案会把大量的开销花费在锁的竞争上面，为了减少公共资源的的抢占可以通过原子变量无锁的编程的方式优化代码。重新执行热点函数分析和锁与等待分析任务可以看到功能函数main和fun2成为了热点函数且已经没有锁函数的调用存在。6.调优结果分析通过热点函数分析和锁与等待分析任务，找到多线程应用代码中公共资源抢占下使用锁机制带来的额外开销，通过原子变量实现无锁编程实现了同样的效果，减少了不必要的开销。一下为实际二进制的运行结果对比，可以看到通过无锁编程以及编译优化下，同样的一个功能应用耗时从5s优化到了1.5s左右。

【Hyper Tuner调优实践 】基于系统性能分析工具的python字符串拼接优化调优介绍Hyper Tuner是一款鲲鹏性能调优工具，本实践中使用Hyper Tuner工具对业务中使用python进行字符串拼接接口执行系统全景分析分析，应用热点函数分析，找到性能瓶颈点，并根据分析结果进行优化修改，从而实现使用python进行字符串拼接性能增强。组网环境说明：本实践以TaiShan 200服务器（型号2280）+ CentOS 7.6组网举例，Hyper Tuner在其他鲲鹏平台和操作系统上的操作类似。表格1 调优环境项目说明服务器TaiShan 200 服务器（型号2280）CPUKunpeng 920 4826OSCentOS 7.6应用python3调优工具Hyper Tuner 2.3.T10 操作步骤      1、python3执行如下demo，该接口中使用“+”在for循环中拼接字符串，该demo耗时约11s      2、进行全景分析操作，按照如下参数创建任务3、全景分析任务结果分析总览页面显示CPU利用率高查看Top数据，内存使用率也较其他进程高 接下来跑应用的热点函数分析任务来观察哪些相关的C API有被调用到。4、创建应用的热点函数分析任务由于python3不在工具默认的路径中，首先配置python3的目录到应用程序路径配置项中返回到工程管理页面，按照下图方式创建性能分析任务5、热点函数任务结果分析查看总览页面的Top热点函数，其中memcpy实现内存中复制，__libc_realloc即malloc函数，用来实现内存的申请及分配，它们消耗了较多的cpu资源性能瓶颈分析综合以上的分析，python中的string是不可变对象，循环中使用+进行大量字符串拼接时，会频繁的进行内存的申请、分配以及字符串的复制，导致性能低下。性能瓶颈优化将代码进行修改，使用join拼接字符串，重复以上操作步骤，查看分析结果注意运行参数修改为string_join系统全景分析任务显示，内存平均使用率降低，持续时间缩短应用热点函数分析任务显示，运行时长降低到之前一半，__libc_realloc不再是TOP热点函数总结字符串拼接方式运行时长%MEM(平均)+拼接11.50s15.59%join拼接5.43s15.52%  

数仓性能调优是数据库应用开发和迁移过程中的关键步骤，在整个项目实施过程中占据很大的份量。它没有明确的衡量标准和对错之分，考验的是资深一线技术人员的隐式技能。如果想成为一个性能调优的高手，除了对应用程序的逻辑做到游刃有余外，还需要了解应用的数据库的基本实现原理，更甚者，需要对操作系统、网络等基础知识有所涉猎，同时还要具备性能诊断和分析技巧。介于此，华为云社区推出了“GaussDB(DWS)性能调优”系列专题，该技术专题由华为云数据库内核技术专家、一线系统工程师撰写，从业务实战经验出发，为开发者介绍数据库级别的性能调优思路和总体策略，包括系统级和语句级调优。本系列文章共分为三部分，前面的基础篇和实战篇聚焦于数仓调优，最后为大家简单介绍数仓产品的最新动态。各位开发者可以通过基础篇文章了解数据库的基本原理，然后结合调优思路，对实战篇的各个调优技巧进行深入的学习。性能调优是一个不断积累的过程，大家不用考虑一步到位，唯有进行实践的积累，才能在广阔的调优战场所向披靡。Part 1: 数仓调优基础篇基础篇介绍性能调优最基本的数据库命令analyze和explain，同时，基于分布式数据库GaussDB(DWS)中产生的分布式计划多种多样的特点，补充对现有分布式计划种类及其性能优劣的详细介绍。⇔  GaussDB(DWS)性能调优系列基础篇一：万物之始analyze统计信息介绍analyze命令，依次解读什么是统计信息，为什么要收集统计信息、怎么收集统计信息以及什么时候应该收集统计信息。⇔  GaussDB(DWS)性能调优系列基础篇二：大道至简explain分布式计划详细解读explain展示的数据库执行计划，介绍如何通过执行计划了解数据库的执行过程、识别性能瓶颈，针对性调优。⇔  GaussDB(DWS)性能调优系列基础篇三：衍化至繁之分布式计划详解基于分布式数据库GaussDB(DWS)中产生的分布式计划多种多样的特点，补充对现有分布式计划种类及其性能优劣的详细介绍。Part 2: 数仓调优实战篇从数据建模、表定义的设计，到数据库硬件、集群部署的选择，再到数据库系统级调优、数据表结构设计，以及单个SQL语句的编写及调优，都要考虑对性能的影响。系统级调优也好，SQL级调优也罢，掌握这十八般武艺，你也能成为一个性能调优高手。⇔  GaussDB(DWS)性能调优系列实战篇一：十八般武艺之总体调优策略介绍数据库级别的性能调优思路和总体策略，包括系统级和语句级调优，本篇主要重点放在系统级调优。⇔  GaussDB(DWS)性能调优系列实战篇二：十八般武艺之坏味道SQL识别发现SQL中的坏味道（导致执行效率低下的SQL语句及其执行方式）是性能调优的前提，本文简要介绍如何通过自诊断视图识别和发现业务中存在的 “坏味道”SQL，以便针对性调优。⇔  GaussDB(DWS)性能调优系列实战篇三：十八般武艺之好味道表定义如何根据数据库特征和产品业务特征，设计合理的表定义，以达到性能提升的目的。⇔  GaussDB(DWS)性能调优系列实战篇四：十八般武艺之SQL改写通过SQL改写提升执行性能，同时改写方法也是数据应用开发过程应该遵循的好SQL的书写习惯。⇔  GaussDB(DWS)性能调优系列实战篇五：十八般武艺之路径干预路径干预方法介绍，路径生成是表关联方式确定的主要阶段，本文讨论几个影响路径生成的要素：cost_param、 scan方式、join方式、stream方式，并从原理上分析如何干预路径的生成。⇔  GaussDB(DWS)性能调优系列实战篇六：十八般武艺Plan hint运用计划干预方法介绍，执行计划数据库执行方式的外在展示，本文讨论如何通过plan hint提示优化器采用更高效的计划，可以使查询执行的性能获得大幅的提升，成为性能调优的一件有利的工具。Part 3: 数仓GaussDB(DWS)产品动态新一代华为云数仓GaussDB(DWS)已广泛应用于金融、政府、运营商、交通、物流、互联网等领域，服务于全球1000+客户，为各行业提供极具竞争力的数据仓库解决方案。⇔  华为云GaussDB(DWS)数据仓库以2048大规模节点通过信通院评测认证⇔  五大关键能力，华为云原生数据仓库GaussDB(DWS)深度技术解读⇔  华为GaussDB(DWS)数据仓库，助力招行“人人用数，创新前行”⇔  数智金融 使能创新，“2020华为数智金融论坛”在溪村成功举办⇔ 华为认证GaussDB OLAP数仓高级工程师 HCIP-GaussDB-OLAP V1.5（中文版）发布通知数仓GaussDB(DWS)开发者论坛：https://bbs.huaweicloud.com/forum/forum-598-1.html数仓GaussDB(DWS)产品主页：https://www.huaweicloud.com/product/dws.html转自，【技术补给站】第2期：数仓性能调优必读：从系统级到SQL级，带你进阶为性能调优高手-云社区-华为云 (huaweicloud.com)

你好，我的Flink作业反压严重，请问如何判断瓶颈点在哪？如何确定是资源不足还是其他问题？

问题描述：roach 备份恢复命令，使用roach的备份和恢复命令 发现 备份速度可以通过调节参数buffer-block-size 来调优，设置4M 比较优（4M速度比起2M，快了近3分之一），但是过了一段时间，换一个比较大的数据2T测试性能，又发现2M和4M速度基本没有区别，都达到了以前比较快的速度（环境是千兆网，GaussDB A版本是8.0.0，没有其他干扰程序运行）问题：请问一下，1 为什么会出现这个情况？2 什么情况 需要调这个参数？3 如何配置这个参数，可以达到速度最优？

子查询SQL语句中子查询的使用非常灵活，但过于复杂的子查询会造成性能问题。先对常见的子查询类别及性能问题判断方法进行介绍。子查询从大类上来看，分为相关性子查询的非相关性子查询。非相关性子查询: 子查询的执行，不依赖于外层父查询的任何属性值。这样子查询具有独立性，可独自求解，形成一个子查询计划先于外层的查询求解.例如：select first_name, last_name from emp where department_id in (select department_id from dept);        上述语句中，子查询select department_id from dept的计算不依赖于外层父查询的任何属性，可以独立求解。因此，非相关性子查询没有性能问题，不需关注。 相关性子查询： 子查询的执行依赖于外层父查询的一些属性值。子查询因依赖于父查询的参数，当父查询的参数改变时，子查询需要根据新参数值重新执行(查询优化器对相关子查询进行优化有一定意义)。例如：select first_name, last_name from emp where department_id in (select department_id from dept where manager_id = emp.employee_id); 上述语句中在，子查询select department_id from dept where manager_id = emp.employee_id依赖于父查询emp表中的employee_id字段，因此是一个相关性子查询。对于相关性子查询，按照场景举例如下，分别进行说明。exists/not exists等值相关子查询select first_name, last_name from emp where not exists (select 1 from dept where manager_id =emp.employee_id and department_id > emp. department_id);select first_name, last_name from emp where exists (select 1 from dept where manager_id =emp.employee_id and department_id > emp. department_id); 上述两个语句为exists/not exists子查询，子查询依赖于外层表emp,因此是相关子查询，针对exists/not exists子查询，如果join条件中有等值条件，则不存在问题。注：如果join条件没有等值条件，则有性能问题。在这种场景下，子查询内只能是单一查询，如存在union/union all/intersect/minus等操作，则存在性能问题，需要将集合操作拆开。带聚集操作的等值相关子查询select first_name, last_name from emp where department_id =  (select max(department_id) from dept where manager_id =emp.employee_id and department_id = emp. department_id);select first_name, last_name from emp where department_id >  (select max(department_id) from dept where manager_id =emp.employee_id and department_id = emp. department_id); 注：如果子查询中join条件有任何一个非等值条件，则存在问题可以是父查询中的某一列等于、大于、小于、大于等于、小于等于、不等于子查询。其他类型相关子查询其他类型相关子查询，如果数据量大(一般为>10万条)，则存在性能问题，需要根据具体场景改写为非相关子查询或上述两类相关子查询。

【功能模块】Spark CarbonData性能能调优创建二级索引【操作步骤&问题现象】1、Spark CarbonData性能能调优创建二级索引，如果创建二级索引的字段是字符串类型或者字符类型可以成功创建，但是字段如果是int或者Bigint创建就会报下面的错误2、创建索引语句：create index catalogreturns_index_crreturnedtimesk on table catalog_returns (cr_returned_time_sk) as 'carbondata' PROPERTIES ('table_blocksize'='128');【截图信息】表结构报错信息【日志信息】（可选，上传日志内容或者附件）

【摘要】 路径生成是表关联方式确定的主要阶段，本文介绍了几个影响路径生成的要素：cost_param, scan方式，join方式，stream方式，并从原理上分析如何干预路径的生成。从另外一个角度看，即路径生成，是从这些底层的选择开始，从行数的估算、到scan的选择、再到join方式以及stream的选择，构成一条简单路径，然后多条路径根据代价选择，再逐层关联更多的表，最终形成一个完整的执行路径。一、cost模型选择顾名思义，cost_param是控制cost相关的一个参数。在了解cost_param之前，先回顾一下选择率的概念，GaussDB优化器中的选择率是指，当一个表有一个过滤或关联条件时，通过该条件能被选中的行数占总行数的比例，是介于0~1之间的一个实数。选择率在优化器中是一个重要的概念，主要应用于行数和distinct值的估算，行数和distinct值是计划生成中的基本要素。首先，我们来看带有过滤条件的基表行数如何估算。如果一个表只有一个过滤条件，那么以选择率乘以表的行数，即可得到过滤完的行数；如果有多个过滤条件，那么就需要算出一个综合的选择率，如何计算？方式有二：一是通过多列统计信息直接计算，二是通过组合单列的选择率。那么组合的方式就由参数cost_param决定了，具体地，取值描述适用场景cost_param = 0选择率按乘积方式组合完全不相关场景cost_param & 2 != 0取最小的选择率作为综合选择率完全相关场景举一个例子，TPC-H 1x的part表，过滤条件是：p_brand = 'Brand#45' and p_container = 'WRAP CASE'，查看不同cost_param下的过滤后行数。（1）cost_param=0（2）cost_param=2从估算出的行数（E-rows）和实际的行数（A-rows）对比可以看出，cost_param=0的不相关模型适合part表的p_brand和p_container列。其次，Join的行数怎么估算的呢？原理跟过滤条件的行数估算是类似的，如果没有多列统计信息可以使用，则也需要单独计算每个条件的选择率，然后计算出综合选择率，得出行数。例如 TPC-H 1x lineitem和orders关联，关联条件是：l_orderkey = o_orderkey and o_custkey = l_suppkey，不同cost_param的执行情况如下：（1）cost_param=0（2）cost_param=2此例中，Join的列之间也适合完全相关模型，这与l_orderkey和l_suppkey的分布是吻合的。由于TPC-H的模型接近完全不相关模型，因此cost_param=0模型可以较好的描述场景，实际应用中，用户可以根据具体业务场景来调整模型，行数估算的准确性是计划生成的重要保证，在调优中检查估算的最直接的地方。GaussDB会在后续版本中新增更多的模型供业务需求选择。二、Scan方式的选择GaussDB中扫描方式主要分顺序扫描和索引扫描，每种扫描方式都对应若干扫描算子，顺序扫描在行列存中对应的扫描算子分别是Seq Scan和CStore Scan算子（下面我们讨论中不加区分）。这些扫描算子大部分都可以通过开关来进行调控，例如Seq Scan，如果设置enable_seqscan=off，则表示不会优先选择Seq Scan，而不是一定不会选。扫描方式的选择，很大程度上决定了获取基表数据的路径。我们以如下的例子来说明：select l_orderkey, o_custkey from lineitem, orders where l_orderkey = o_orderkey;lineitem分布键是l_orderkey，并且在l_orderkey上有index，orders分布键是o_orderkey。默认情况下，Scan的方式如下：两个表都是顺序扫描的路径，关联方式选择了Hash Join。如果把Seq Scan关掉（enable_seqscan=off）,计划如下：lineitem的扫描变成了Index Only Scan（因为l_orderkey的类型是int），而在orders表上仍然选择Seq Scan（因为没有其他路径），同时关联方式也变为了Nest Loop，因为Hash Join需要全表扫描数据（lineitem的Seq Scan已经被关掉了）。优化器的选择方式我们从代价（E-costs）一栏中也可以看出。再把Index Only Scan关掉，看看计划如何变化：扫描路径都变为了Seq Scan，而且Seq Scan的代价都很大。此时既然都走了Seq Scan，为什么不选Hash Join呢，把Nest Loop关掉，看看Hash Join计划的代价：从代价上看出Hash Join的总代价比Nest Loop的小，但优化器没有选择Hash Join，这是因为优化器比较路径代价时，会比较Startup和Total代价，即启动代价和总代价，综合考虑，E-costs栏中显示的是总代价。把explain_perf_mode设置为normal，查看原Nest Loop的启动代价：红框中的两个cost，分别是启动代价和总代价，在看Hash Join的cost，明显Hash Join的启动代价比Nest Loop的大很多（启动代价代表了输出第一条数据的代价），优化器在比较路径时，综合了这两个代价，最终推荐了Nest Loop的路径。从上面的例子可以看出，扫描路径的调控，可以改变路径生成，合理的搭配是生成最优计划的前提，默认情况下，GaussDB优化器可以根据现有的路径选择（如上面的lineitem有两条扫描路径，orders只有一条扫描路径），最后确定出最优的一条。两条路径代价比较时，总代价不是唯一要素，但总代价越小，一般也会越容易被选中。三、关联方式的选择GaussDB优化器中表关联的主要方式有：Nest Loop，Hash Join和Merge Join，分别可以通过enable_nestloop、enable_hashjoin、enable_mergejoin进行控制，这种控制也不是绝对的，可以理解为是否优先选择。大部分场景下，三种路径的代价关系：Hash Join < Merge Join < Nest Loop。我们以一个简单的关联示例说明，store_returns和store_sales是TPC-DS 1x中两个表，SQL如下：select count(*) from store_returns, store_sales where sr_customer_sk = ss_customer_sk;默认情况下，优化器推荐Hash Join路径，计划如下：如果把Hash Join关掉，则优化器选择了Merge Join路径：如果再把Merge Join路径关掉，可能就会选择Nest Loop路径。关联方式的控制开关一般用于调优或规避问题，但具体是否能够起作用要看具体的语句，除了当前关联方式，还有没有其他方式。实际场景中，一个语句中关联的算子较多，一般很难用参数enable_hashjoin或enable_nestloop或enable_mergejoin来控制某两个表的Join方式，GaussDB中更细致的语句级别的调优手段是Plan Hint，感兴趣的读者可以参考产品手册。四、Stream方式的选择Stream算子是GaussDB分布式执行的关键算子之一，主要起到网络传输的作用，概要介绍可以参考：GaussDB(DWS)性能调优系列实战篇一：十八般武艺之总体调优策略。Stream算子由参数enable_stream_operator控制，如果关掉Stream算子，则可能导致生成不下推的计划，例如：因为lineitem表关联的键l_partkey不是lineitem的分布键，需要添加Stream算子，但Stream功能被禁，于是只能生成不下推计划。GaussDB计划中常见的主要Stream算子包括Redistribute、Broadcast和Gather。Gather一般是分布式计划中，CN用于收集DN的数据进行最后的处理，除非最后收集的行数非常多，这个算子涉及性能问题一般较少。Redistribute和Broadcast一是对“互补”的算子，前者用于重分布，后者用于广播，生成计划时，优化器会根据代价大小来选择。当Join Key没有包含表的分布键的时候，一般会添加Redistribute路径，能选择Redistribute路径理论上也可选择Broadcast路径，最终选择哪条路径要看优化器估算的代价是多少。这两个算子可以通过参数enable_redistribute和enable_broadcast进行控制。在SMP开启的情况下，当并行度（dop）大于1时，一般还会有Local Redistribute、Split Redistribute、Local Broadcast和Split Broadcast；当倾斜优化开启时，还有PART REDISTRIBUTE PART ROUNDROBIN、PART_REDISTRIBUTE_PART_BROADCAST、PART_REDISTERIBUTE_PART_LOCAL等等，这些也是Stream算子，主要就是重分布、广播、RoundRobin的一些扩展形式，这里我们不一一介绍了，感兴趣的读者可以参考GaussDB DWS 产品手册。我们考虑两个表的简单关联，store_sales和sr_tbl，它们的分布键分别是ss_item_sk 和sr_returned_date_sk，Join 条件是store_sales.ss_customer_sk =sr_tbl. sr_customer_sk，执行结果如下：由于两个表的分布键都不是Join Key，因此走Hash Join路径的话需要有一个表做Broadcast或者两个表都做Redistribute，但是store_sales表比较大（E-rows显示28.7亿行），而sr_tbl表行数估算比较少（E-rows显示100行），优化器认为适合做Broadcast。于是最终选择了一边Broadcast的计划。对于这个计划，由于sr_tbl表统计信息不准确（如果是中间结果集，则表示中间结果集估算不准），一种调优的方法是，将sr_tbl的表统计信息重新收集准确一些（如果sr_tbl是中间结果集，则无法收集），另一种方法是让sr_tbl走Redistribute路径，而后者我们又有两种方式来实现，一是用Plan Hint，即在生成计划时，告诉优化器走Redistribute路径，二是把Broadcast关掉。禁用Broadcast后，执行计划如下：本列中，开启了SMP自适应，即优化器会根据系统资源和当前Active SQL数量来自行决定并行度（dop），如果Redistribute和Broadcast选择不当，则可能导致（1）Broadcast计划会出现下盘（2）两个计划的并行度不一样，最终执行时间可能会差异比较大。对于Stream方式的控制，一般的调优方式有Plan Hint、GUC参数、改善统计信息或估算信息。Plan Hint的详细介绍可以参考产品手册或者：GaussDB(DWS)性能调优系列实战篇六：十八般武艺Plan hint运用。五、结束语本文介绍的cost_param属于cost底层参数，建议对数据特征和使用场景比较熟悉的DBA慎重使用。Scan、Join、Stream调控的基本依据也是代价，代价一般体现在执行耗时上，调优时可从Performance中识别出性能的瓶颈点，分析选择的算子是否与代价匹配。另外，除了本文介绍的Session级别的控制参数外，还有基表、中间结果的行数，也可以通过Plan Hint进行语句级别的调控，感兴趣读者可通过GaussDB DWS产品文档进一步了解。原文链接：https://bbs.huaweicloud.com/blogs/212459【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

【摘要】 GaussDB在执行SQL语句时，会对其性能表现进行分析和记录，通过视图和函数等手段呈现给用户。本文将简要介绍如何利用GaussDB提供的这些“第一手”数据，分析和定位SQL语句中存在的性能问题，识别和消除SQL中的“坏味道”。SQL语言是关系型数据库（RDB）的标准语言，其作用是将使用者的意图翻译成数据库能够理解的语言来执行。人类之间进行交流时，同样的意思用不同的措辞会产生不同的效果。类似地，人类与数据库交流信息时，同样的操作用不同的SQL语句来表达，也会导致不同的效率。而有时同样的SQL语句，数据库采用不同的方式来执行，效率也会不同。那些会导致执行效率低下的SQL语句及其执行方式，我们称之为SQL中的“坏味道”。         下面这个简单的例子，可以说明什么是SQL中的坏味道。图1-a 用union合并集合         在上面的查询语句中，由于使用了union来合并两个结果集，在合并后需要排序和去重，增加了开销。实际上符合dept_id = 1和dept_id > 2的结果间不会有重叠，所以完全可以用union all来合并，如下图所示。图1-b 用union all合并集合         而更高效的做法是用or条件，在扫描的时候直接过滤出所需的结果，不但节省了运算，也节省了保存中间结果所需的内存开销，如下图所示。图1-c 用or条件来过滤结果         可见完成同样的操作，用不同的SQL语句，效率却大相径庭。前两条SQL语句都不同程度地存在着“坏味道”。         对于这种简单的例子，用户可以很容易发现问题并选出最佳方案。但对于一些复杂的SQL语句，其性能缺陷可能很隐蔽，需要深入分析才有可能挖掘出来。这对数据库的使用者提出了很高的要求。即便是资深的数据库专家，有时也很难找出性能劣化的原因。         GaussDB在执行SQL语句时，会对其性能表现进行分析和记录，通过视图和函数等手段呈现给用户。本文将简要介绍如何利用GaussDB提供的这些“第一手”数据，分析和定位SQL语句中存在的性能问题，识别和消除SQL中的“坏味道”。◆ 识别SQL坏味道之自诊断视图         GaussDB在执行SQL时，会对执行计划以及执行过程中的资源消耗进行记录和分析，如果发现异常情况还会记录告警信息，用于对原因进行“自诊断”。用户可以通过下面的视图查询这些信息：•       gs_wlm_session_info•       pgxc_wlm_session_info•       gs_wlm_session_history•       pgxc_wlm_session_history         其中gs_wlm_session_info是基本表，其余3个都是视图。gs_开头的用于查看当前CN节点上收集的信息，pgxc_开头的则包含集群中所有CN收集的信息。各表格和视图的定义基本相同，如下表所示。表1 自诊断表格&函数字段定义名称类型描述datidoid连接后端的数据库OID。dbnametext连接后端的数据库名称。schemanametext模式的名字。nodenametext语句执行的CN名称。usernametext连接到后端的用户名。application_nametext连接到后端的应用名。client_addrinet连接到后端的客户端的IP地址。 如果此字段是null，它表明通过服务器机器上UNIX套接字连接客户端或者这是内部进程，如autovacuum。client_hostnametext客户端的主机名，这个字段是通过client_addr的反向DNS查找得到。这个字段只有在启动log_hostname且使用IP连接时才非空。client_portinteger客户端用于与后端通讯的TCP端口号，如果使用Unix套接字，则为-1。query_bandtext用于标示作业类型，可通过GUC参数query_band进行设置，默认为空字符串。block_timebigint语句执行前的阻塞时间，包含语句解析和优化时间，单位ms。start_timetimestamp with time zone语句执行的开始时间。finish_timetimestamp with time zone语句执行的结束时间。durationbigint语句实际执行的时间，单位ms。estimate_total_timebigint语句预估执行时间，单位ms。statustext语句执行结束状态：正常为finished，异常为aborted。abort_infotext语句执行结束状态为aborted时显示异常信息。resource_pooltext用户使用的资源池。control_grouptext语句所使用的Cgroup。min_peak_memoryinteger语句在所有DN上的最小内存峰值，单位MB。max_peak_memoryinteger语句在所有DN上的最大内存峰值，单位MB。average_peak_memoryinteger语句执行过程中的内存使用平均值，单位MB。memory_skew_percentinteger语句各DN间的内存使用倾斜率。spill_infotext语句在所有DN上的下盘信息：None：所有DN均未下盘。All: 所有DN均下盘。[a:b]: 数量为b个DN中有a个DN下盘。min_spill_sizeinteger若发生下盘，所有DN上下盘的最小数据量，单位MB，默认为0。max_spill_sizeinteger若发生下盘，所有DN上下盘的最大数据量，单位MB，默认为0。average_spill_sizeinteger若发生下盘，所有DN上下盘的平均数据量，单位MB，默认为0。spill_skew_percentinteger若发生下盘，DN间下盘倾斜率。min_dn_timebigint语句在所有DN上的最小执行时间，单位ms。max_dn_timebigint语句在所有DN上的最大执行时间，单位ms。average_dn_timebigint语句在所有DN上的平均执行时间，单位ms。dntime_skew_percentinteger语句在各DN间的执行时间倾斜率。min_cpu_timebigint语句在所有DN上的最小CPU时间，单位ms。max_cpu_timebigint语句在所有DN上的最大CPU时间，单位ms。total_cpu_timebigint语句在所有DN上的CPU总时间，单位ms。cpu_skew_percentinteger语句在DN间的CPU时间倾斜率。min_peak_iopsinteger语句在所有DN上的每秒最小IO峰值（列存单位是次/s，行存单位是万次/s）。max_peak_iopsinteger语句在所有DN上的每秒最大IO峰值（列存单位是次/s，行存单位是万次/s）。average_peak_iopsinteger语句在所有DN上的每秒平均IO峰值（列存单位是次/s，行存单位是万次/s）。iops_skew_percentinteger语句在DN间的IO倾斜率。warningtext显示告警信息。queryidbigint语句执行使用的内部query   id。querytext执行的语句。query_plantext语句的执行计划。node_grouptext语句所属用户对应的逻辑集群。         其中的query字段就是执行的SQL语句。通过分析每个query对应的各字段，例如执行时间，内存，IO，下盘量和倾斜率等等，可以发现疑似有问题的SQL语句，然后结合query_plan（执行计划）字段，进一步地加以分析。特别地，对于一些在执行过程中发现的异常情况，warning字段还会以human-readable的形式给出告警信息。目前能够提供的自诊断信息如下：◇多列/单列统计信息未收集         优化器依赖于表的统计信息来生成合理的执行计划。如果没有及时对表中各列收集统计信息，可能会影响优化器的判断，从而生成较差的执行计划。如果生成计划时发现某个表的单列或多列统计信息未收集，warning字段会给出如下告警信息：Statistic Not Collect:schemaname.tablename(column name list)         此外，如果表格的统计信息已收集过（执行过analyze），但是距离上次analyze时间较远，表格内容发生了很大变化，可能使优化器依赖的统计信息不准，无法生成最优的查询计划。针对这种情况，可以用pg_total_autovac_tuples系统函数查询表格中自从上次分析以来发生变化的元组的数量。如果数量较大，最好执行一下analyze以使优化器获得最新的统计信息。◇SQL未下推         执行计划中的算子，如果能下推到DN节点执行，则只能在CN上执行。因为CN的数量远小于DN，大量操作堆积在CN上执行，会影响整体性能。如果遇到不能下推的函数或语法，warning字段会给出如下告警信息：SQL is not plan-shipping, reason : %s◇Hash连接大表做内表         如果发现在进行Hash连接时使用了大表作为内表，会给出如下告警信息：PlanNode[%d] Large Table is INNER in HashJoin \"%s\"目前“大表”的标准是平均每个DN上的行数大于100，000，并且内表行数是外表行数的10倍以上。◇大表等值连接使用NestLoop         如果发现对大表做等值连接时使用了NestLoop方式，会给出如下告警信息：PlanNode[%d] Large Table with Equal-Condition use Nestloop\"%s\"目前大表等值连接的判断标准是内表和外表中行数最大者大于DN的数量乘以100，000。◇数据倾斜         数据在DN之间分布不均匀，可导致数据较多的节点成为性能瓶颈。如果发现数据倾斜严重，会给出如下告警信息：PlanNode[%d] DataSkew:\"%s\", min_dn_tuples:%.0f, max_dn_tuples:%.0f目前数据倾斜的判断标准是DN中行数最多者是最少者的10倍以上，且最多者大于100,000。◇代价估算不准确         GaussDB在执行SQL语句过程中会统计实际付出的代价，并与之前估计的代价比较。如果优化器对代价的估算与实际的偏差很大，则很可能生成一个非最优化的计划。如果发现代价估计不准确，会给出如下告警信息："PlanNode[%d] Inaccurate Estimation-Rows: \"%s\" A-Rows:%.0f, E-Rows:%.0f目前的代价由计划节点返回行数来衡量，如果平均每个DN上实际/估计返回行数大于100,000，并且二者相差10倍以上，则认定为代价估算不准。◇Broadcast量过大         Broadcast主要适合小表。对于大表来说，通常采用Hash+重分布（Redistribute）的方式效率更高。如果发现计划中有大表被广播的环节，会给出如下告警信息：PlanNode[%d] Large Table in Broadcast \"%s\"目前对大表广播的认定标准为平均广播到每个DN上的数据行数大于100,000。◇索引设置不合理  如果对索引的使用不合理，比如应该采用索引扫描的地方却采用了顺序扫描，或者应该采用顺序扫描的地方却采用了索引扫描，可能会导致性能低下。索引扫描的价值在于减少数据读取量，因此认为索引扫描过滤掉的行数越多越好。如果采用索引扫描，但输出行数/扫描总行数>1/1000，并且输出行数>10000（对于行存表）或>100（对于列存表），则会给出如下告警信息：PlanNode[%d] Indexscan is not properly used:\"%s\", output:%.0f, filtered:%.0f, rate:%.5f顺序扫描适用于过滤的行数占总行数比例不大的情形。如果采用顺序扫描，但输出行数/扫描总行数<=1/1000，并且输出行数<=10000（对于行存表）或<=100（对于列存表），则会给出如下告警信息：PlanNode[%d] Indexscan is ought to be used:\"%s\", output:%.0f, filtered:%.0f, rate:%.5f◇下盘量过大或过早下盘         SQL语句执行过程中，因为内存不足等原因，可能需要将中间结果的全部或一部分转储的磁盘上。下盘可能导致性能低下，应该尽量避免。如果监测到下盘量过大或过早下盘等情况，会给出如下告警信息：•       Spill file size large than 256MB•       Broadcast size large than 100MB•       Early spill•       Spill times is greater than 3•       Spill on memory adaptive•       Hash table conflict         下盘可能是因为缓冲区设置得过小，也可能是因为表的连接顺序或连接方式不合理等原因，要结合具体的SQL进行分析。可以通过改写SQL语句，或者HINT指定连接方式等手段来解决。         使用自诊断视图功能，需要将以下变量设成合适的值：▲ use_workload_manager（设成on，默认为on）▲ enable_resource_check（设成on，默认为on）▲ resource_track_level（如果设成query，则收集query级别的信息，如果设成operator，则收集所有信息，如果设成none，则以用户默认的log级别为准）▲ resource_track_cost（设成合适的正整数。为了不影响性能，只有执行代价大于resource_track_cost语句才会被收集。该值越大，收集的语句越少，对性能影响越小；反之越小，收集的语句越多，对性能的影响越大。）         执行完一条代价大于resource_track_cost后，诊断信息会存放在内存hash表中，可通过pgxc_wlm_session_history或gs_wlm_session_history视图查看。         视图中记录的有效期是3分钟，过期的记录会被系统清理。如果设置enable_resource_record=on，视图中的记录每隔3分钟会被转储到gs_wlm_session_info表中，因此3分钟之前的历史记录可以通过gs_wlm_session_info表或pgxc_wlm_session_info视图查看。◆ 发现正在运行的SQL的坏味道         上一节提到的自诊断视图可以显示已完成SQL的信息。如果要查看正在运行的SQL的情况，可以使用下面的视图：•       gs_wlm_session_statistics•       pgxc_wlm_session_statistics         类似地，gs_开头的用于查看当前CN节点上收集的信息，pgxc_开头的则包含集群中所有CN收集的信息。两个视图的定义与上一节的自诊断视图基本相同，使用方法也基本一致。 通过观察其中的字段，可以发现正在运行的SQL中存在的性能问题。         例如，通过“select queryid, duration from gs_wlm_session_statistics order by duration desc limit 10;”可以查询当前运行的SQL中，已经执行时间最长的10个SQL。如果时间过长，可能有必要分析一下原因。图2-a 通过gs_wlm_session_statistics视图发现可能hang住SQL         查到queryid后，可以通过query_plan字段查看该SQL的执行计划，分析其中可能存在的性能瓶颈和异常点。图2-b 通过gs_wlm_session_statistics视图查看当前SQL的执行计划         再下一步，可以结合等待视图等其他手段定位性能劣化的原因。图2-c 通过gs_wlm_session_statistics视图结合等待视图定位性能问题         另外，活动视图pg_stat_activity也能提供一些当前执行SQL的信息。◆ Top SQL——利用统计信息发现SQL坏味道         除了针对逐条SQL进行分析，还可以利用统计信息发现SQL中的坏味道。另一篇文章“Unique SQL特性原理与应用”中提到的Unique SQL特性，能够针对执行计划相同的一类SQL进行了性能统计。与自诊断视图不同的是，如果同一个SQL被多次执行，或者多个SQL语句的结构相同，只有条件中的常量值不同。这些SQL在Unique SQL视图中会合并为一条记录。因此使用Unique SQL视图能更容易看出那些类型的SQL语句存在性能问题。         利用这一特性，可以找出某一指标或者某一资源占用量最高/最差的那些SQL类型。这样的SQL被称为“Top SQL”。         例如，查找占用CPU时间最长的SQL语句，可以用如下SQL：select unique_sql_id,query,cpu_time from pgxc_instr_unique_sql order by cpu_time desc limit 10。         Unique SQL的使用方式详见https://bbs.huaweicloud.com/blogs/197299。◆ 结论         发现SQL中的坏味道是性能调优的前提。GaussDB对数据库的运行状况进行了SQL级别的监控和记录。这些打点记录的数据可以帮助用户发现可能存在的异常情况，“嗅”出潜在的坏味道。从这些数据和提示信息出发，结合其他视图和工具，可以定位出坏味道的来源，进而有针对性地进行优化。原文链接：https://bbs.huaweicloud.com/blogs/197413【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

1.问题背景某局点出现如下业务场景：从存量清单表中，根据条码，合同号等条件，查询明细数据，表总数据量有3亿。一次业务请求包含10个并发的查询语句，需要1秒内返回结果集。但是多次优化之后并发性能依旧长达4s左右。2.   硬件配置硬件配置信息：集群 6个数据节点：每个节点都是RH5885服务器，配置1T内存、 144个CPU core、SSD 存储空间3.   历史优化对于这个业务场景需求，客户做了多种性能优化尝试，优化动作主要分为如下三个阶段l  第一版本：调试分布键分析业务数据特性，并测试验证选择最合适的分布键，既能保障数据不倾斜，又能利用分布键做为条件过滤数据调整后单个查询响应从平均9秒降到4~5秒l  第二版本：添加PCK&限制结果集接口上线后，发现业务中会有几个高频条件字段，同时有些查询返回结果集过大，有几十万记录，不符合前端查询响应要求，所以添加了限制，单次最大只能返回1万条记录；同时对合同号添加了PCK调整后单个查询响应从平均5秒降到2秒l  第三版本：使用SMP，以资源换性能从系统监控发现资源使用率低，建议使用SMP，通过提高CPU资源使用率的方式提升查询性能。根据现网CPU配置推荐设置query_dop=8调整后单个查询响应从2秒降到了400MS版本上线后，生产使用发现查询性能劣化到3~4秒，但是把SQL提取之后单独运行时性能达到400ms。分析平台日志发现下日志中会每10个请求发起时间点很接近，然后再找到下游调用方了解，才确认是会每此业务请求包含10个类似SQL语句的并发调用。后续测试确认并发查询时性能下降，导致性能不达标。4.   优化分析4.1. SQL语句分析业务SQL是如下简单的单表查询语句，SQL语句未发现明显的不下推、不能提升子查询等明显低效性能点。需要进一步获取performance信息分析性能瓶颈。4.2. 性能瓶颈分析执行并发查询，获取performance信息，典型信息如下，详细信息见附件 发现耗时主要有两个1)  数据收集（GATHER和LOCAL GATHER），这个算子主要是从相关线程收集数据，这个算子耗时一般分为两个场景 数据量大，导致数据收集耗时特别长CN申请线程，DN上创建STREAM线程等计算相关线程初始化耗时长2)   数据扫描(Scan)耗时长分析Scan算子，发现顺序扫描（Cstore Scan）时，RoughCheck（根据稀疏索引排除查询不相关的数据）时排除掉的元组为0，即稀疏索引没有预过滤掉任何CU根据上述分析可以看到当前查询性能主要损耗在计算相关线程初始化上，但是如果把SMP去掉（设置query_dop为1），底层数据扫描耗时会变长，同样导致性能不达标。和相关维护和业务人员也确认了这点4.3. 性能优化4.3.1. 优化思路找到性能瓶颈点之后就可以针对性进行性能优化，我们把优化的重点放在Scan性能的提升上，期待在不设置SMP时通过Scan性能的大幅提升来优化性能。根据表扫描信息分析，我们发现，表扫描的filter条件可以过滤掉376029639条记录，输出149条记录，可以过滤掉99.99996037%的元组，效果非常明显。 分析表的扫描条件，通过测试验证发现过滤效果最明显的条件为POSITION(','||a.ItemNo||',' in ','||'0835TXWY'||',') > 0，过滤效果在99.99%以上，其它表达式基本没有起到过滤效果进一步分析RoughCheck，发现RoughCheck排除掉的元组为0，稀疏索引没有任何过滤效果 通常来讲，这类过滤效果非常明显的filter是典型的构建PCK和索引场景，但是这个filter条件为函数表达式，导致此filter条件即没有办法构建PCK又没办法构建索引。因此我们尝试跟业务人员沟通，看能够改写POSITION约束，使其支持索引和PCK4.3.2. 业务分析跟客户业务人员进一步沟通position函数的业务含义，发现1.  position函数的第二个参数如果个合同号通过’,’连接起来的子串2.  函数功能是查询能跟匹配到第二个参数中任一合同号的记录第二个参数通过如下的方式从客户端输入这样写的原因是从在客户界面上操作的方便性以及常规的操作习惯上来讲，在外部输入时不会在合同号上引号，在SQL拼接时不能把此约束条件写成itemno in ('0AFR2C', ‘0A672C’, ’0A902C', '0AY72C'')这类索引支持的表达式4.3.3. 最终优化方案在了解这些原因之后，我们和业务人员沟通，采取以下优化手段1)   在业务层在接受客户界面输入的合同号之后，内部在拼接SQL之前，进行数据预处理，把函数的逻辑转化为itemno in ('0AFR2C', ‘0A672C’, ’0A902C', '0AY72C'')式的in约束2)  在itemno上建PCK以及索引，通过PCK和索引的双重优化来提升性能采取这两个措施之后，标准并发测试场景下，SQL查询性能提升到90ms，端到端的性能从4s提升到300ms5.   优化总结5.1.       关于列存点查性能通常场景下，列存表的点差性能比行存表的点查性能要差，但是在如下场景下列存表的索引查询性能也非常好1）宽表的少量列查询列存是按照列存储的，宽表的少量列查询时，列存表只需要读取少量查询相关列即可，这可能会导致列存表扫描的数据量小于行存表的数据量，体现列存表扫描的性能优势2）索引列上局部聚簇通过在索引列上做PCK，通过PCK的聚簇效果减小扫描的CU个数，导致列存表扫描的数据量小于行存表的数据量。注：行存表有全局聚簇的手段，详见产品文档的CLUSTER命令5.2.       关于优化思路SQL语句优一些建议：1)  梳理性能问题业务，找出执行性能差的SQL语句2)  分析业务流程，确认SQL全生命周期的耗时分布，如果数据库执行时间长，那么进入下一步3)  分析是否存在不下推场景。如果存在，通过改写SQL消除不下推因素，如果SQL语句可以下推，进入下一步4)  通过performance找性能瓶颈点：根据performance显示的算子耗时，查询耗时最长的算子，这个算子就是导致执行耗时时间比较长的最基本因素5)  针对性能瓶颈点，给出优化思路和方案优化不要局限在SQL语句本身，要和具体硬件配置和业务背景相结合。名词解释1. 【CU】列存的基本存储单元，同时也是列存表扫描时基本的读取单元。列存表读取数据时会把全部CU的数据读上来，而不能读取CU中的一部分数据。2. 【PCK】Partial Cluster Key（局部聚簇）的简称，是列存表的一种局部聚簇技术，该技术可以在批量数据导入时，把数据按照PCK指定的列(单列或多列)进行局部排序，实现不同值区间的数据存储到不同的CU上。这种局部聚簇结合列存表CU的内置min/max稀疏索引，可以大幅提升表在PCK列上简单filter的过滤效果使用PCK需要注意的几点1)  只有列存表支持PCK2)  一个表只能定义一个PCK3)  PCK列上的fliter要满足以下约束 简单的<、>、≤、≥、=表达式 一侧是PCK列，而不能是列相关表达式、函数另一侧是常量表达式计算时，PCK列不需要进行隐士类型转换4)  上个步骤的filter条件要可以过滤掉较多的元组，减轻Scan以及相关投影计算量5)  表数据是批量数据入库，且单次入库数据不小于DN的个数*6w * 5条记录；如果单次入库记录数不满足上述约束，建议把表建成分区表，定期对增强数据所在分区进行VACUUM FULL操作增强聚簇效果6)  通过ALTER语法增加PCK时，只有后续新增数据才会有局部聚簇效果。可以通过VACUUM FULL全表让已有数据恢复聚簇3. 【SMP】SMP特性通过算子并行(可以理解为把一个线程的任务拆分为多个线程并行执行)来提升性能，本质上是一种以资源换取时间的方式，在合适的场景以及资源充足的情况下，能够起到较好的性能提升效果；但是如果在不合适的场景下，或者资源不足的情况下，反而可能引起性能的劣化。GaussDB A中可以通过参数query_dop设置算子并行度4. 【RoughCheck】粗过滤检查，列存表扫描的特殊的优化手段。在列存表简单filter条件（单列 op 常量， op为>、<、=、≤、≥）过滤时，通过判断CU的内置min/max跟filter条件进行快速比较，如果此CU内是不满足filter条件，那么直接跳过此CU的扫描。GaussDB A的列存表通过PCK +RoughCheck+Latter Read(先读取filter条件列进行过滤、再读取非filter条件列数据) 组合技术，可以典型场景下节省大量的数据扫描，提升查询性能原文链接：https://bbs.huaweicloud.com/blogs/175458【推荐阅读】【最新活动汇总】DWS活动火热进行中，互动好礼送不停（持续更新中）  HOT  【博文汇总】GaussDB(DWS)博文汇总1，欢迎大家交流探讨~（持续更新中）【维护宝典汇总】GaussDB(DWS)维护宝典汇总贴1，欢迎大家交流探讨（持续更新中）【项目实践汇总】GaussDB(DWS)项目实践汇总贴，欢迎大家交流探讨（持续更新中）【DevRun直播汇总】GaussDB(DWS)黑科技直播汇总，欢迎大家交流学习（持续更新中）【培训视频汇总】GaussDB(DWS) 培训视频汇总,欢迎大家交流学习（持续更新中）扫码关注我哦，我在这里↓↓↓

尊敬的微认证客户：您好！为保证您获得最佳的学习与实验体验，华为云学院将于2021年2月25日对《鲲鹏软件性能调优实践》微认证的课程及实验进行下线优化，预计将于2020年3月19日重新上线，届时请您关注相关通知。为此，我们将采取以下措施：1．对于已购买该微认证并通过考试领取证书的客户，原证书在证书有效期内仍有效，并与课程优化后的证书拥有同等效力；2．对于已购买该微认证但未通过考试且仍有考试机会的客户，可在重新上线后进行新课程学习、实验，参加考试并领取证书；3．对于已购买该微认证但未完成实验操作的客户，请您关注华为云学院资讯专栏-业务动态的上线通知，待实验优化重新上线后再前往沙箱开展实验。如您有任何问题，可随时通过工单或者服务热线（+86-4000-955-988 ）与我们联系。感谢您对华为云微认证的支持！ 发布日期：2021年2月24日

摘要      开工大吉！小编特意给大家整理了“GaussDB(DWS)性能调优“系列专题！该技术专题由华为云数仓内核专家、资深数仓解决方案工程师撰写，从业务实践经验出发，为开发者介绍数仓知识、性能调优黑科技及开发实践小技巧，带您进阶为数仓性能调优高手，文末有福利，华为云限量定制T恤等你来拿，活动即刻开始，快来mark学习吧~本系列文章分为三个部分：GaussDB(DWS)产品动态、GaussDB(DWS)性能调优系列专题、GaussDB(DWS)案例实践分享。各位读者朋友们可以通过本文了解数仓的基本原理、学习数仓调优黑科技，然后结合案例实践技巧进行深入的开发技能学习。part1: 数仓GaussDB(DWS)产品动态重定义数据仓库，释放数仓非凡价值！新一代华为云数仓GaussDB(DWS)已广泛应用于金融、政府、运营商、交通、物流、互联网等领域，服务于全球1000+客户，为各行业提供极具竞争力的数据仓库解决方案。⇔  华为云GaussDB(DWS)数据仓库以2048大规模节点通过信通院评测认证⇔  五大关键能力，华为云原生数据仓库GaussDB(DWS)深度技术解读⇔  华为GaussDB(DWS)数据仓库，助力招行“人人用数，创新前行”⇔  数智金融 使能创新，“2020华为数智金融论坛”在溪村成功举办⇔ 华为认证GaussDB OLAP数仓高级工程师 HCIP-GaussDB-OLAP V1.5（中文版）发布通知part2: 数仓GaussDB(DWS)性能调优-基础篇数仓GaussDB(DWS)性能调优基础篇介绍性能调优最基本的数仓命令analyze和explain，同时，基于数仓GaussDB(DWS)中产生的分布式计划多种多样的特点，补充对现有分布式计划种类及其性能优劣的详细介绍。⇔  GaussDB(DWS)性能调优基础篇一：万物之始analyze统计信息介绍analyze命令，依次解读什么是统计信息、为什么要收集统计信息、怎么收集统计信息以及什么时候应该收集统计信息。⇔  GaussDB(DWS)性能调优系列基础篇二：大道至简explain分布式计划详细解读explain展示的数仓执行计划，介绍如何通过执行计划了解数仓的执行过程、识别性能瓶颈，针对性调优。⇔  GaussDB(DWS)性能调优系列基础篇三：衍化至繁之分布式计划详解基于分布式数仓GaussDB(DWS)中产生的分布式计划多种多样的特点，补充对现有分布式计划种类及其性能优劣的详细介绍。数仓GaussDB(DWS)性能调优-实战篇从数据建模、表定义的设计，到数仓硬件、集群部署的选择，再到数仓系统级调优、数据表结构设计，以及单个SQL语句的编写及调优，都要考虑对性能的影响。系统级调优也好，语句级调优也罢，掌握这十八般武艺，你也能成为一个性能调优高手。⇔  GaussDB(DWS)性能调优系列实战篇一：十八般武艺之总体调优策略介绍数仓级别的性能调优思路和总体策略，包括系统级和语句级调优，本篇主要重点放在系统级调优。⇔  GaussDB(DWS)性能调优系列实战篇二：十八般武艺之坏味道SQL识别发现SQL中的坏味道（导致执行效率低下的SQL语句及其执行方式）是性能调优的前提，本文简要介绍如何通过自诊断视图识别和发现业务中存在的 “坏味道”SQL，以便针对性调优。⇔  GaussDB(DWS)性能调优系列实战篇三：十八般武艺之好味道表定义如何根据数仓特征和产品业务特征，设计合理的表定义，以达到性能提升的目的。⇔  GaussDB(DWS)性能调优系列实战篇四：十八般武艺之SQL改写通过SQL改写提升执行性能，同时改写方法也是数据应用开发过程应该遵循的好SQL的书写习惯。⇔  GaussDB(DWS)性能调优系列实战篇五：十八般武艺之路径干预路径干预方法介绍，路径生成是表关联方式确定的主要阶段，本文讨论几个影响路径生成的要素：cost_param、 scan方式、join方式、stream方式，并从原理上分析如何干预路径的生成。⇔  GaussDB(DWS)性能调优系列实战篇六：十八般武艺Plan hint运用计划干预方法介绍，执行计划数仓执行方式的外在展示，本文讨论如何通过plan hint提示优化器采用更高效的计划，可以使查询执行的性能获得大幅的提升，成为性能调优的一件有利的工具。part3: 数仓GaussDB(DWS)案例实践分享⇔ GaussBD(DWS)内存自适应控制技术介绍数仓GaussDB(DWS)引入了内存自适应控制的技术，在SQL语句复杂、处理数据量大的AP场景下，能够对运行的作业进行内存级的管控，避免高并发场景下内存不足产生的各种问题。⇔ 侵略如火，GaussDB(DWS)数仓高可用容灾利器之逻辑备份在大数据时代，数据的完整和可靠性成为一个数仓最核心的能力之一。如果企业、政府因为硬件故障导致数据丢失、误删，损失将是不可估量的。本文着重于讲解数仓GaussDB(DWS)推出的一款主力的备份恢复工具——Roach逻辑备份的实现原理。⇔ PB级数仓GaussDB(DWS)性能黑科技之并行计算技术解密GaussDB(DWS)开发了并行计算技术，在语句执行时可以充分利用硬件资源进行并行加速，提高执行的吞吐率。本文将详细介绍GaussDB(DWS)并行计算技术的原理，以及其在performance信息中的展示，帮助各位开发者朋友更好地分析并行的性能。等等，DWS还给大家准备了开工大奖↓↓↓现在只需关注GaussDB(DWS)公众号并分享本文至朋友圈即有机会抽取华为云限量定制T恤！本次活动共5个获奖名额！活动时间：即日始至2021年2月28日23:59（中奖信息将在结束后5个工作日内公示）PS：小伙伴记得将朋友圈分享截图反馈到公众号后台参与抽奖哦~快快转发参与起来，get开工好礼吧！！！备注：添加微信小助手”GaussDBDWS”加入GaussDB(DWS)大神学习分享群：（最新的学习资源、活动信息，小助手会跟您一起分享哦）扫码关注我哦，我在这里↓↓↓*本活动最终解释权归华为云数仓GaussDB(DWS)所有。【了解更多】数仓GaussDB(DWS)开发者论坛：https://bbs.huaweicloud.com/forum/forum-598-1.html数仓GaussDB(DWS)产品主页：https://www.huaweicloud.com/product/dws.html活动结束中奖信息公示：（请中奖用户添加小助手微信号”GaussDBDWS”，反馈您的信息）中奖名单公示恭喜*江川健一*12楼恭喜*十三姨*23楼恭喜*起风了*26楼恭喜*Ploseatience*39楼恭喜*南海*41楼*中奖信息均按照后台反馈截图编号，由线上抽奖助手随机抽取，感谢您的参与！

调优介绍    Hyper Tuner是一款鲲鹏性能调优工具，本实践中使用Tuning Kit工具对sqlite3所在系统执行系统性能全景分析，找到性能瓶颈点，并根据分析结果进行优化修改，从而实现sqlite3多数据插入性能增强。组网环境说明：本实践以TaiShan 200服务器（型号2280）+ Ubuntu18.04.1组网举例，TuningKit在其他鲲鹏平台和操作系统上的操作类似。表格1 sqlite3环境项目说明服务器TaiShan   200 服务器（型号2280）CPUKunpeng     920 4826OSUbuntu 18.04.1应用Sqlite3   python3调优工具Hyper Tuner     2.2.T3 前提条件1.     服务器和操作系统正常运行。2.     PC端已经安装SSH远程登录工具。3.     目标环境上HyperTuner工具已经安装完成，并正常运行。调优思路1.     执行调优之前的代码，用HyperTuner工具对目标环境的空载系统进行全局的系统性能分析。2.     对全景性能分析中，有异常的指标进一步分析，并根据优化建议进行优化修改。3.     对优化后的代码再次进行全景性能分析，验证调优后的效果。操作步骤系统全景分析python3执行附件中的demo.py，此时插入2000000条数据，每次执行的时候就会执行conmmit操作（执行指令 python3 demo.py）数据插入很慢，20秒钟只能插入几百条数据进行全景分析操作性能瓶颈分析在性能全景分析的结果中，查看CPU利用率中的%iowait以及存储IO中的%util，发现CPU等待存储I/O操作导致空闲状态的时间占CPU总时间的百分比 很高，在I/O请求发送到设备期间所消耗的CPU时间百分比也很高，说明程序在执行磁盘操作的时间很长，查看代码，发现是每一条插入语句都得和磁盘交互一次。性能瓶颈优化将代码进行修改，附件中的demo1.py，采用多插入的代码，执行结果如下：，20秒可以执行几十万的数据，插入很快（操作指令：python3 demo1.py）进行全景分析操作调优后结果查看CPU利用率中的%iowait以及存储IO中的%util，发现有明显下降，数据插入也变快了很多。本实践中，通过系统全景分析的采集，一步步找到代码中对于的优化点，主要是cpu等待磁盘操作的时候太长，导致性能较低，通过优化，提高性能总结20秒数据%util%iowaitSqlite单插入400+条数据98.80%52.32%Sqlite多插入（1000条每次）16W+条数据74.00%40.37%

发表日期作者博文标题地址10月9日李太松光大银行基于华为云GaussDB(DWS)   数据仓库创新实践https://bbs.huaweicloud.com/blogs/20272010月9日李太松SoundNet迁移学习-由声音分类到语音情感识别https://bbs.huaweicloud.com/blogs/14549710月10日ModelArts3.0   发布，一个让机器狗学会灭火的AI神器https://bbs.huaweicloud.com/blogs/19794610月10日胡琦    （华为云云享专家）【Copy攻城狮日志】ModelArts与AppCube双“魔”合璧庆双节https://bbs.huaweicloud.com/blogs/19831310月12日郑毅HDC.Cloud |   前沿技术探秘：知识图谱构建流程及方法https://bbs.huaweicloud.com/blogs/15313010月13日李明磊【论文笔记】一种有效攻击BERT等模型的方法https://bbs.huaweicloud.com/blogs/15119210月14日李明磊全面解读文本情感分析任务https://bbs.huaweicloud.com/blogs/13430610月15日杜晗侵略如火，GaussDB数仓高可用容灾利器之逻辑备份https://bbs.huaweicloud.com/blogs/19846110月15日王晶文字识别在计算机视觉的重要性、基本技术和最新进展（OCR系列一）https://bbs.huaweicloud.com/blogs/11850010月16日李升GaussDB(DWS)数据同步状态查看方法https://bbs.huaweicloud.com/blogs/19853610月16日李静标注数据不足下的深度学习方法概述https://bbs.huaweicloud.com/blogs/18814010月19日文玉生GaussDB(DWS)运维管理系列基础篇一：升级介绍与展望https://bbs.huaweicloud.com/blogs/19821310月20日殷成明GaussDB(DWS)性能调优系列基础篇二：大道至简explain分布式计划https://bbs.huaweicloud.com/blogs/19794510月21日胡琦    （华为云云享专家）献礼1024，华为云EI极速开发开源问答机器人<a href="https://bbs.huaweicloud.com/blogs/<span =">https://bbs.huaweicloud.com/blogs/19896510月21日李岱城HBase   2.X版本的元数据修复及一种数据迁移方式https://bbs.huaweicloud.com/blogs/19907510月22日金鑫AI助力，视频分析全面进入智能时代https://bbs.huaweicloud.com/blogs/17501010月22日戚亚东数据湖探索DLI重磅发布   基于openLooKeng的交互式分析功能https://bbs.huaweicloud.com/blogs/19938710月23日为什么说容器的崛起预示着云原生时代到来？https://bbs.huaweicloud.com/blogs/20039510月23日杜奇1024程序员节华为内部分享丨开发者如何抓住时代机遇，学好AI？https://bbs.huaweicloud.com/blogs/19988910月23日华为云如何赋能无人车飞驰？从这群AI热血少年谈起https://bbs.huaweicloud.com/blogs/20084410月28日初识人脸识别服务 走进刷脸时代https://bbs.huaweicloud.com/blogs/19571010月28日李岱城HBase实用技巧：一种全量+增量数据的迁移方法https://bbs.huaweicloud.com/blogs/19939910月29日李茂增 GaussDB(DWS)性能调优系列实战篇一：十八般武艺之总体调优策略https://bbs.huaweicloud.com/blogs/20090610月29日Brijoo BopannaApache   CarbonData、Hudi及Open Delta的对比研究https://bbs.huaweicloud.com/blogs/19908410月30日熊坤机器狗如何利用ModelArts强化学习算法更改导航轨迹https://bbs.huaweicloud.com/blogs/19846710月30日蔡子建AI-机器学习-K近邻算法简介（二）https://bbs.huaweicloud.com/blogs/20151010月31日张婧垚GaussDB(DWS)性能调优系列实战篇二：十八般武艺之坏味道SQL识别https://bbs.huaweicloud.com/blogs/197413