摘要      开工大吉！小编特意给大家整理了“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

【功能模块】【操作步骤&问题现象】1、agg的时候sum(case when里有to_char和to_date，发现性能很差，优化成immtable的函数后性能从6分钟提升到40秒2、pck的列为columnA和columnB，只过滤columnB的情况下pck会提高性能么？我实际试了试试提高了性能的，但是我之前理解应该是只有按照columnA或者columnA+columnB过滤才会有效，请教下为啥【截图信息】【日志信息】（可选，上传日志内容或者附件）

最近给伙伴的业务系统做鲲鹏凌云认证系统这样部署的简单做了个300并发压测，发现数据库服务器CPU到100%了这个不让过，怎么办啊，当然是盘它上数据库服务器看看Mysql配置文件长啥样真干净，跟新买的一样加点料，我猜伙伴用的innodb伙伴业务系统查询场景远多于增删改，配置查询缓存看看好使不CPU稳了，响应时间降了，吞吐量升了，多来点用户搞搞稳得一匹，早睡晚起完了么？为啥是900并发呢？再加一倍1200稳得住吗？现实是看来瓶颈是在应用服务器先提交报告了，有人想看再继续优化

报错如下， 请告知对处方法start to install malluma_v2  malluma_v2 packages Decompressing...  malluma_v2 packages Decompress Success!  The installed openssl version check: OK  Create malluma certificate successfully.cp: cannot stat ‘/home/malluma/malluma_cert/key/ca.pem’: No such file or directorycp: cannot stat ‘/home/malluma/malluma_cert/key/ca.pem’: No such file or directorycp: cannot stat ‘/home/malluma/malluma_cert/key/server.pem’: No such file or directorycp: cannot stat ‘/home/malluma/malluma_cert/key/client.pem’: No such file or directory  /home/malluma/malluma_cert/key/ca.pem does not exist!  /home/malluma/malluma_cert/key/ca.srl does not exist!  /home/malluma/malluma_cert/key/client.csr does not exist!  /home/malluma/malluma_cert/key/client.pem does not exist!  /home/malluma/malluma_cert/key/server.csr does not exist!  /home/malluma/malluma_cert/key/server.pem does not exist!  Encrypt malluma certificate successfully.Tue 17 Nov 2020 11:08:12 [INFO] [MALLUMA] check user permission success.Tue 17 Nov 2020 11:08:13 [INFO] [MALLUMA] The avaliable space in installation dictionary is 14194M.Following parameters will be used for installation:    Install user name       : malluma    Install directory       : /opt/tuning_kit/sys_perf/malluma    Install Mode            : all    Server IP address       : 192.168.1.14    Server host name        : Malluma    Server port number      : 50051    Client local IP address :    Install silently        : False    Server side certificate file path        : /home/malluma/malluma_cert/server    Client side certificate file path        : /home/malluma/malluma_cert/client    Plugin BMC login configuration file path : nullTue 17 Nov 2020 11:08:13 [INFO] [MALLUMA] Begin to install Malluma ...Tue 17 Nov 2020 11:08:13 [WARNING] [MALLUMA] User malluma already exist!Tue 17 Nov 2020 11:08:14 [INFO] [MALLUMA] Successfully add permission!Tue 17 Nov 2020 11:08:14 [ERROR] [MALLUMA] /home/malluma/malluma_cert/client/malluma_cacert.pem does not                                                          exist!Tue 17 Nov 2020 11:08:14 [ERROR] [MALLUMA] Invalid client certificate file path: /home/malluma/malluma_ce                                                         rt/clientTue 17 Nov 2020 11:08:14 [ERROR] [MALLUMA] Error: Install Malluma failed!  install malluma_v2 failed!  install malluma failed

 摘要：那些会导致执行效率低下的SQL语句及其执行方式，我们称之为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 自诊断表格&函数字段定义其中的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级别的监控和记录。这些打点记录的数据可以帮助用户发现可能存在的异常情况，“嗅”出潜在的坏味道。从这些数据和提示信息出发，结合其他视图和工具，可以定位出坏味道的来源，进而有针对性地进行优化

 摘要： 性能调优是应用迁移或开发过程中的关键步骤，同时也在整个项目实施过程中占据很大的份量，本篇主要介绍数据库级别的性能调优思路和总体策略。性能调优是应用迁移或开发过程中的关键步骤，同时也在整个项目实施过程中占据很大的份量，在很多实施步骤中都需要进行考虑，从开始的数据建模，表定义的设计，到数据库硬件、集群部署的选择，再到数据库系统级调优、数据表结构设计，以及单个SQL语句的编写及调优，都要考虑对性能的影响。同时，性能调优通常没有明确的衡量标准，没有明确的对错之分，通常需要的隐式技能比较多，使得其的技术含金量得以提升。通常来看，要做到一个性能调优的高手，除了对于应用程序的逻辑做到游刃有余外，还需要对应用的数据库的基本实现原理有所了解，更甚者，还需要对操作系统、网络等基础知识有所涉猎，同时还要具备性能诊断和分析技巧。当然，性能调优是一个不断积累的过程，大家不用考虑一步到位，唯有进行实践的积累，才能在广阔的调优战场所向披靡。本篇博文作为《GaussDB(DWS)性能调优系列》的专题文章，主要介绍数据库级别的性能调优思路和总体策略，包括系统级和语句级调优。同时，《GaussDB(DWS)性能调优系列》文章分为基础篇和实战篇，各位读者在通过基础篇文章了解数据库的基本原理后，可以结合调优思路，对实战篇的各个调优技巧进行深入的学习。有关整个调优过程中的其它方面，后续论坛会推出其它博文进行介绍。1. GaussDB DWS执行架构及说明GaussDB DWS是典型的share-nothing架构，其计算组件的示意图如上图所示，主要由CN（Coordinator）和DN（DataNode）组成。CN是整个集群的协调者，是整个集群与应用进行连接处理的门户，用于接收客户的SQL语句并返回执行结果。DN是集群进行数据计算的主体，各个DN拥有独立的存储和计算资源，使得各个DN可以独立地进行计算。GaussDB DWS支持多CN架构，通常应用程序会通过LVS（负载均衡设备）将语句均匀分发到各个CN上，以减少单个CN的瓶颈作用。GaussDB DWS的SQL处理流程如上方右图所示，其包含以下几个主要步骤：（1）CN通过驱动或客户端接收到一条SQL后，会进行解析、优化，并最终返回执行结果；（2）CN进行优化后，生成相应的执行计划；（3）CN将相同的执行计划下发到各个DN进行执行；（4）如果DN之间需要进行数据交换，则执行计划中包含流操作算子Stream，DN之间同步通过Stream算子进行数据交换，共同完成计划的执行并向CN返回结果。同时，GaussDB DWS对于不需要DN间数据交换的语句，还支持语句下发到DN生成计划；对于部分不支持分布式查询的语句，生成不能下推的计划（此计划对于大数据量性能较差）。各种计划的对比可详见博文《GaussDB(DWS)性能调优系列基础篇三：衍化至繁之分布式计划详解》。本文后续的讨论均基于Stream计划。2. 整体调优思路通过前面对SQL语句执行流程的介绍，我们可以知道，性能瓶颈可能发生在CN端、DN端，以及结果集返回，驱动数据处理等环节，性能调优的第一步就是定位瓶颈点主要发生在哪个环节。由于GaussDB DWS大数据量处理时，大部分执行时间消耗在DN端，故本博文主要针对DN端语句执行进行总体调优思路的分享。谈到执行性能，其实从数据模型建模、集群部署、表结构设计，到最终的SQL语句优化，都与之紧密相关，如上图所示，我们使用金字塔来描述整个调优过程。越接近塔尖，其对于整个业务性的影响范围越广，需要调优时，调优成本也越高，所以在设计之初需要投入足够精力，从上至下，我们需要全面的设计，才能减少在最终SQL调优时返工的可能。整个调优过程其实是一个不断迭代的过程，如上图所示。即使设计再严密，也有可能出现SQL语句性能的优化需要导致数据建模更改、集群部署、表分布键调整的情况，这时一发动全身将引起较高的成本，同时会对其它已经调优完毕的SQL产生影响，导致重新调优，成本较高。我们统一将前三阶段归结为静态调优，将SQL语句级调优归结为执行态调优。下面重点来探讨执行态调优-SQL语句调优，从调优步骤来看可以分为性能瓶颈诊断、性能原因分析和调优项实施，从调优实施对象来看，可能包括前面提到的数据建模、集群部署、表结构设计方面的修改，SQL语句层调优可以分为系统级调优和语句级调优。当然，有一些调优项，例如系统调优项，可以作为经验固化下来，在集群部署的时候就一并设置好，减少这方面调优花费的成本。同时，SQL调优也是一个迭代的过程，在实施一次调优项后，需要继续重新进行调优分析，直至性能达到标准为止。后面的章节，将围绕调优步骤和SQL层的调优项来开展。3. 性能瓶颈诊断GaussDB DWS提供了丰富的计划信息显示工具Explain，以及动态执行信息分析工具Top SQL。Explain工具主要针对单个语句进行展示，可以使用explain命令显示CN生成的SQL语句的计划，也可以使用explain analyze/performance命令显示执行态信息。通过执行态信息，我们可以分析出算子为单位的性能，也可以分析出算子内部各步骤的性能，进一步为诊断性能的瓶颈打下了基础。Explain工具相关内容请参考博文《GaussDB(DWS)性能调优系列基础篇二：大道至简explain计划信息》。Top SQL工具则针对集群中运行的语句进行整体性能分析，其包含12个视图，可以将执行时间超过一定设置阈值的语句的执行状态、执行结果进行实时查询，同时可以设置将其转储用作后续分析。附加于该工具之上的SQL自诊断调优工具，则通过瓶颈点的分析，给出可能的性能原因分析。同时，我们还提供Unique SQL工具，进行一类SQL的性能持续跟踪，可以用于发现系统资源及硬件问题对SQL性能产生的影响。Top SQL工具相关内容请参考博文《GaussDB(DWS)性能调优系列实战篇二：十八般武艺之坏味道SQL识别》。4. 性能原因分析性能原因分析属于性能调优里的高阶知识了，通常要对数据库的执行实现原理有基本了解才能够逐步深入下去。本章节将深入浅出地介绍数据库执行实现原理的基本技术，帮助各位读者朋友能够有兴趣去主动查找性能产生的原因，从而自己找到性能调优的方法。前面已经对GaussDB DWS的执行流程进行了介绍，由CN生成执行计划下发到DN去执行。GaussDB DWS是基于代价来生成计划的，因此需要依据基表的统计信息，进行每一步结果集统计信息的估算，根据数据规模的场景从GaussDB DWS支持的备选算子中选择最优的算子组合成计划进行执行。因此，统计信息是计划准确的前提，在执行SQL语句前要确保收集最新的统计信息，有关统计信息的收集可以参见博文《GaussDB(DWS)性能调优系列基础篇一：万物之始analyze统计信息》。由于统计信息只包含基表的统计信息，表关联之后的统计信息只能通过估算得到，因此仍然可能存在估算不准的情况。GaussDB DWS针对不同的SQL语句中的操作，为每个操作内部实现了不同的算子。每个算子可能在部分场景下是占优的，但其它场景比较差。SQL优化时，根据具体的场景去自动匹配最优的算子。如果存在估算不准，将导致算子选择出现失误，从而计划较差，此时就需要根据计划的瓶颈来分析具体的原因了。通常情况下，GaussDB处理的操作类型主要分为：扫描算子（Scan）、关联算子（Join）、聚集算子（Agg）和网络传输算子（Stream）。下表列出了各算子类别的使用场景，以及各类别中可选的算子，及其适用范围，同时列出调优场景，供大家参考。（1）扫描算子（Scan）：主要用于处理从存储扫描数据，返回上层算子，包括：全表扫描算子、索引扫描算子，其中行列存均对应不同的全套扫描算子，索引扫描包括：IndexScan（普通索引扫描）、IndexOnlyScan（仅扫描索引即可获得结果）、BitmapScan（需要索引扫描获取位图后再到基表上扫描），BitmapScanAnd/Or（从多个索引扫描进行位图运算后再到基表上扫描），由于索引扫描的原理基本都相同，故一并探讨。（2）关联算子（Join）：主要用于处理表的关联操作。在数据库中，多表关联时，SQL优化会选择关联顺序进行两两关联。表关联时可以包含关联操作，也可以没有关联操作（笛卡尔积）。在GaussDB DWS中，主要包含NestLoop, HashJoin, MergeJoin三种关联算子。（3）聚集算子（Agg）：（4）网络传输算子（Stream）：（5）其它算子：同时GaussDB DWS还支持排序（Sort）、集合（SetOp）、物化（Materialize）、窗口聚集（WindowAgg）和输出限制（Limit）算子，由于调优基本不涉及，故此处略过。5. 调优项实施在知道导致性能问题的原因后，就可以制定调优项并开始实施了。前面已经提到，调优项实施的范围很广。本博文仅探讨数据库级的调优项，包括系统级调优和语句级调优两部分。a)系统级调优项系统级调优又细分为操作系统参数调优和数据库全局参数调优，通常涉及到的是系统CPU、IO、内存、网络资源的充分使用，避免资源冲突，提升整个系统查询的吞吐量。由于数据库是运行在操作系统之上的，因此操作系统资源的利用率对于数据库性能的提升起到基石的作用。对于操作系统参数的调优，主要集中在操作系统内存参数、IO参数以及网络参数的设置上，具体可参见GaussDB DWS产品文档。数据库级别的调优，主要也是集中在上述资源的使用上，在上述四维度有以下主要因素的考虑（具体设置方法可以参见GaussDB DWS产品文档）：b)语句级调优项语句级调优通常需要通过计划分析，找到性能瓶颈点，然后根据瓶颈点对应的扫描、关联、聚集、Stream等算子，分析是否属于算子适用场景，是否符合调优条件。如果是，我们有以下调优手段：i. 通过修改表定义，包括行列存、表的分布方式，达到减少IO和网络资源开销的目的，详见博文《GaussDB(DWS)性能调优系列实战篇三：十八般武艺之好味道表定义》。ii. 如果最终分析是由于估算不准导致，可以通过相关GUC参数调整来设置不同的结果集估算模型，或禁止生成某种类型的算子，通过改进估算值达到优化计划的目的，详见博文《GaussDB(DWS)性能调优系列实战篇五：十八般武艺之路径干预》。iii.如果在迁移或升级过程中出现计划劣化，也可以通过Plan Hint的调优方式干预优化器生成理想的计划，详见博文《GaussDB(DWS)性能调优系列实战篇六：十八般武艺Plan hint运用》。iv.对于上述调优手段都无法解决的问题，例如：下推问题，相关子查询提升，NOT IN等问题，或者SQL语句存在计算冗余等问题，需要根据瓶颈点选择灵活多变的SQL改写策略消除瓶颈点，具体可参见博文《GaussDB(DWS)性能调优系列实战篇四：十八般武艺之SQL改写》总的来说，性能调优是一项艰巨的工程，当然深入其中，学习到的知识以及获得的收获都是非常大的。后续论坛也会推出更多的博文对性能调优的方方面面进行介绍，帮助各位读者迅速积累调优的经验

【摘要】 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级别的监控和记录。这些打点记录的数据可以帮助用户发现可能存在的异常情况，“嗅”出潜在的坏味道。从这些数据和提示信息出发，结合其他视图和工具，可以定位出坏味道的来源，进而有针对性地进行优化。【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区），文章链接，文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至：huaweicloud.bbs@huawei.com进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。

直播回看地址：https://bbs.huaweicloud.com/webinar/100019“全部直播”部分选择技术领域“Gauss AP”可以查看到全部直播内容本次直播是五节课的系列课程，课程计划如下：第三天直播会深入讲解事务与锁机制管理，资源负载管理，性能调优，安全与权限设计，非常具有实操性。扫描以下海报二维码即可进入直播间，也可通过链接进入：https://huawei.vhallyun.com/fe/watch/5145【学习福利】想要利用坐地铁，排队等零碎时间来学习专业数据库知识吗？马上扫描华为云AI微信公众号“华为云AI”，带给你不一样的资讯，除了华为云数仓及人工智能相关技术类精品文章外，也可以手机端登陆论坛提问并查看技术分享。GaussDB(DWS)产品主页：https://www.huaweicloud.com/product/dws.html     GaussDB(DWS)产品主页二维码HCIP-GaussDB-OLAP认证介绍与预约考试：https://e.huawei.com/cn/talent/#/cert/product-details?certifiedProductId=195&authenticationLevel=CTYPE_CARE_HCIP&technicalField=PSC&version=1.0

Presto是一个分布式的查询引擎，本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询。详情请点击博文链接：https://bbs.huaweicloud.com/blogs/173486

第二期活动——大厂面试必备：PB级数据仓库性能调优来了，它来了，没错，继第一次之后，他又来了！本次直播干货多多，老师不仅讲解理论，做了分析，还有实际操作环节，结合具体示例进行了代码级别的详细展示，分享了很多华为云自研PB级数据仓库的特色及优势，以及，结合了具体的业务场景分享了一些通用的调优手段和性能问题方法，在此分享一下观看直播的心得以及收获。首先了解了GaussDB分布式架构，这个主要是做下简单的介绍，让第一次来的小伙伴了解一下。大体架构如图所示哦：在这个节点收到业务请求之后，会做解析和规划，然后下发任务，大体有如下模块组成，这些在上面的图中都有说明介绍的，而且进行了关系的简单梳理，方便大家了解记忆，PPT做的很贴心呀。OM：运维管理模块（Operation Manager）提供日常运维、配置管理的管理接口、工具；CM：集群管理模块（CluSter Mgnager)管理和监控分布式系统中各个功能单元和物理资源的运行情况，确保整个系统的稳定运行；Coordinator：整个系统的业务入口和结果返回;接收来自业务应用的访问请求;分解任务并调度任务分片的并行执行；GTM：全局事务控制器（Global Transaction Manager）提供全局事务控制所需的信息，采用多版本并发控制MVCC机制；WLM：工作负载管理器（Workloed Manager）控制系统资源的分配，防止过量业务负载，对系统的冲击导致业务拥塞和系统崩溃；Data Node：执行查询任务分片的逻辑实体。重头戏是关于如何优化的，提高效率。数据库优化的基本准则是“资源利用最大化”；而资源主要是指CPU、内存、磁盘IO、网络IO这四种资源。所有的调优手段都是围绕资源使用开展的。简而言之，就是将尽最大可能“压榨”资源，发挥资源的硬件极限性能。资源利用最大化有两层含义：1. SQL语句应当尽量高效：用最小的代价实现指定目标，比如点查询索引扫描要比顺序扫描代价更小。2. SQL语句应当充分利用资源：在没有资源瓶颈的情况下单一的SQL语句要尽量用更多的资源去执行，以此来提高效率。没错，就是这张PPT的主要内容：那么该如何进行调试优化呢？下面就是调优的基本流程了：调优可分为静态调优和执行态调优两部分哦！根据具体执行业务的不同时间可以分为两个阶段，首先是静态调优，通过定制化设计优化来达到我们想要的最佳的性能。如果未没有达到性能预期，则需要分析瓶颈原因，并通过调整参数等手段，再进行优化设计，这也就是第二种执行态调优。具体过程在老师的PPT中有详细的介绍，可以看看。最后，就是实际操作案例讲解了，以实际的实例作为分析的对象，从代码讲到应用，并做了简单的操作时间，真是很棒了！通过这次学习，学习到很多，了解了调优的基本原则，学习了调优过程和基本方法，更是通过实际操作进行了巩固，感觉收获满满，谢谢老师和小姐姐的分享！下次还来哦！

调优介绍    TuningKit是一款鲲鹏性能调优工具，本实践中使用Tuning Kit工具对MySQL所在系统执行系统配置全景分析、性能全景分析以及函数分析，找到性能瓶颈点，并根据分析结果进行优化修改，从而实现MySQL系统的性能增强。组网环境说明：本实践以TaiShan 200服务器（型号2280）+CentOS7.6组网举例，TuningKit在其他鲲鹏平台和操作系统上的操作类似。表格1 MySQL环境项目说明服务器TaiShan 200 服务器（型号2280）CPUKunpeng   920 4826OSCentOS   7.6应用MySQL   8.0.17调优工具TuningKit   2.2.0 表格 2 压力测试环境项目说明服务器TaiShan 200 服务器（型号2280）CPUKunpeng   920 4826OSCentOS   7.6压力测试工具Benchmark   5.0 前提条件1.     服务器和操作系统正常运行。2.     PC端已经安装SSH远程登录工具。3.     MySQL数据库已经安装完成，并启动。4.     压力测试环境和MySQL环境网络互通。5.     压力测试环境中Benchmark 5.0已经安装完成，并完成与MySQL数据库连接，可以进行压力测试。6.     MySQL环境上TuningKit工具已经安装完成。调优思路1.     在进行调优之前，先用Benchmark工具测试MySQL在并发100个进程的性能数据。2.     使用TuningKit调优工具针对MySQL应用从函数分析、系统性能、系统配置维度进行性能分析。并根据性能分析结果得出性能瓶颈点以及优化方法。3.     针对性能瓶颈点分别进行性能优化。完成优化后，分别再用Benchmark工具测试MySQL并发100个进程的性能数据，与调优之前的性能进行对比，判断性能是否有提升。操作步骤调优前数据库性能测试Benchmark测试1.     进入Linux系统后台的BenchMark目录。cd /home/ BenchMarkSQL/run/2.     运行Benchmarksql程序。说明：参考鲲鹏社区https://support.huaweicloud.com/tstg-kunpengdbs/kunpengbenchmarksql_06_0004.html中的BenchMarkSQL测试MySQL章节，修改压测环境中Benchmark配置文件，包括数据库服务器地址、端口、数据库名称、数据库用户账号和密码等连接参数和进程并发参数loadWorkers。修改完配置文件后，执行./runDatabaseBuild.sh和./runBenchmark.sh 命令，运行benchmarksql程序，查看tpmTOTAL的值为138104    MySQL应用的热点函数性能调优热点函数分析3.     登录性能调优工具。4.     创建MySQL工程。       创建MySQL工程时，需要选择MySQL所在的服务器节点。5.     创建C/C++性能分析任务，配置参数如下图所示。          从分析结果中的热点函数列表中可以发现，MySQL运行的Top1热点函数queued_spin_lock_slowpath调用栈占用了超过一半的运行时间。         热点函数分析及优化方法热点函数分析：从C/C++性能分析的Top10函数列表中可以看出，内核热点函数queued_spin_lock_slowpath调用栈占用了超过一半的运行时间，内核函数queued_spin_lock_slowpath调用栈中，存在大量的futex_wait函数和futex_wake函数，则判断内核中的线程频繁的保持和唤醒spin lock锁，从而占用大量的运行时间。因此需要减少MySQL进程进入内核态的次数，避免spin lock被频繁保持和唤醒。优化方法：通过查看MySQL官方手册(https://dev.mysql.com/doc/refman/8.0/en/innodb-performance-spin_lock_polling.html)中关于spin_lock的介绍，，MySQL引入了innodb_spin_wait_delay参数，控制自旋锁时间，同时引入innodb_sync_spin_loops参数，控制自旋锁的循环次数。因此，可以用CPU计算资源换取MySQL进程内核态次数。即通过修改MySQL数据库配置文件，增加spin_loop的次数以及wait_delay的时间长度，防止自旋锁循环过快，尽量避免MySQL进程陷入内核态引起spin lock被频繁保持和唤醒，以此来调优MySQL性能。通过查看华为鲲鹏社区(https://support.huaweicloud.com/tngg-kunpengdbs/kunpengmysql8017_05_0015.html)中，对MySQL数据库参考调优中，将innodb_spin_wait_delay设置为180，innodb_sync_spin_loops设置为25，会达到最优性能。修改MySQL配置文件6.     修改mysql的配置文件    执行vi /etc/my.cnf 命令编辑配置文件，将tune中的参数做如下修改，防止进入系统自旋。    innodb_spin_wait_delay=180    innodb_sync_spin_loops=25    7.     执行重启MySQL命令，使配置文件生效。    /etc/init.d/mysql restart重启热点函数分析重新启动之前创建过的C/C++性能分析任务，任务执行结束后，发现spin_lock自旋热点函数被消除，函数执行时间由29.9秒降低到17.3秒。Benchmark测试8.     进入Linux系统后台的Benchmark运行目录。cd /home/ BenchMarkSQL/run/9.     执行./runBenchmark.sh命令，运行Benchmarksql程序。    查看tpmTOTAL的值由之前的138104变为当前的699282，性能提升明显。        系统配置和性能调优系统性能和配置全景分析10.  登录性能调优工具。11.  创建MySQL工程。创建MySQL工程时，需要选择MySQL所在的服务器节点。12.  创建系统性能全景分析任务，配置参数如下图所示。    13.  查看系统性能指标1.     CPU利用率：从%soft参数值中，可以看到48号核的CPU服务软中断所花费时间占CPU总时间的99.71%，说明软中断集中在48号核上，需要做中断绑核优化。          2.     网络IO指标：观察网络设备统计数据，发现MySQL使用的网口每秒传输数据包和字节数超过基准值，按优化建议需要做网口中断绑核。        为了查看系统中有多少中断，以及中断在每个核上的分布情况，需要进一步执行配置全景分析。          14.  创建系统配置全景分析任务，配置参数如下图所示。        15.  检查系统硬件信息中的网卡中断NUMA绑核信息，可以看到有32个中断在numa node中随机分布。（中断NUMA绑核数据列表较多，可以下载到本地后查看）      中断绑核分析及优化方法中断绑核分析：1.     从系统性能全景分析结果，发现48号核的CPU服务软中断所花费时间占CPU总时间的99.71%，中断的分布不合理。同时网络设备统计中，网口每秒传输数据包和字节数超过基准值，按优化建议需要做网口中断绑核。2.     从配置全景分析结果中查看MySQL Server使用的网卡中断NUMA绑核信息，可以看到32个中断在numa node中是随机分布的，所以会导致多个中断都集中在某一个核上，还会有概率性跨numa_node和片的风险。优化方法：    根据中断NUMA绑核的优化建议和方法，进行网卡的中断绑核操作，将32个中断均匀绑定在一个node节点的24个核上。    使用cat /sys/class/net/enp189s0f0/device/numa_node命令查询数据库通信网卡设备靠近numa_node 2，所以可以将该网卡中断绑定在numa_node 2对应的24个核上。    网口中断绑核中断绑核方法一：手动执行绑核命令，对每个中断逐个绑核。工具的优化建议中有提供绑核步骤。中断绑核方法二：将绑核执行命令写入脚本中，循环多次，批量绑核。如下为已经写好的irq.sh绑核脚本（请参见附件），可以根据实际情况修改绑核规则。从脚本内容中可以看出将中断循环绑定到一个numa中24个核上。（Kunpeng920 4826机型一个numa_node有24个核）        16.  将irq.sh绑核脚本上传到MySQL Server目录下。1） 执行systemctl status irqbalance.service命令查询负载均衡的服务状态，如果服务状态为active状态，需要执行systemctl stop irqbalance.service命令，停止负载均衡服务。停止后，查询状态为inactive状态。    2）执行sh irq.sh enp189s0f0命令，将32个中断绑在一个node 节点的24个核上。    重启系统性能和配置全景分析任务1.     重启系统性能全景分析任务完成后，观察%soft指标（该指标表示CPU服务软中断所花费时间占CPU总时间的百分比），可以看到相比于中断绑核之前，软中断的处理分散在了绑定的核上。    2.       重启系统配置全景分析任务后，观察硬件信息的网卡指标。绑核前中断随机分配在numa节点的核上，会有概率性跨numa_node和片的风险，也可能集中占用某一个核；中断绑核后中断有序的固定在绑定的核上，中断处理分散在这些核上，提高了处理器的效率。绑核后中断分布如下所示。    Benchmark测试17.  进入Linux系统后台的Benchmark运行目录。        cd /home/ BenchMarkSQL/run/18.  执行./runBenchmark.sh命令运行Benchmarksql程序。        查看tpmTOTAL值由之前的699282变为当前的704005，性能有所提升。             调优结果分析本实践中，经过对MySQL系统进行了热点函数和中断绑核两次调优后，Benchmark测试MySQL的tpmTOTAL值从138104提升到704005，数据库性能提升410%。在进行其他应用调优时，需要根据性能调优工具采集分析的实际结果和对应的优化建议进行调优操作。具体的调优思路和调优过程，可以参考本实践。

去年10月24日我们发布了《鲲鹏性能调优十板斧V1.0》，发布后引发开发者及行业合作伙伴们强烈反响。今天我们发布2.0版本，在去年的基础上增加了更多的调优方法：1、单队列网卡中断散列，避免中断集中在一个core上导致系统瓶颈；2、TCP checksum算法优化，提升网络性能；3、使用NEON加速应用性能，充分发挥鲲鹏特性；4、更多java应用调优方法，java应用调优不再发愁；欢迎大家下载查阅，并留言讨论。调优的路上，期待我们更多的碰撞和交流，不断地完善调优方法！

昇腾学院 | Atlas性能调优之瓶颈分析https://bbs.huaweicloud.com/blogs/155497昇腾学院 | Atlas性能调优之流程编排https://bbs.huaweicloud.com/forum/thread-44630-1-1.html昇腾学院 | Atlas性能调优之编解码https://bbs.huaweicloud.com/forum/thread-45650-1-1.html