环境鲲鹏 920 128 核Bisheng JDK 17.0.1 / 17.0.4运行 BenchmarkSQL + ShardingSphere-JDBC网卡队列绑核 0-15，BenchmarkSQL 绑核 16-127。现象概率性出现运行 BenchmarkSQL us 较高（几乎压满 CPU 核），sy 较低。之前使用的是 GraalVM EE，本来以为是 GraalVM EE 才有的现象，后续测试发现使用 Bisheng JDK 17 也有相似现象。多次启动 BenchmarkSQL 进程，性能时好时坏。正常情况下，使用 BenchmarkSQL + ShardingSphere-JDBC 性能可以达到 200 万 tpmC 以上。最近启动进程时有较高概率发生性能异常，性能相比正常情况下降约 30%。Bisheng JDK 17 现象正常情况us 相对较低，网卡中断几乎跑满前 16 核。正常情况下 tpmC 在 200 万左右。异常现象最近测试发现，经常出现 us 较高，中断相比性能正常时更低。tpmC 在 160 万左右。性能下降至正常的 70% 左右。升级 Bisheng JDK 17.0.4 问题未解决async-profiler 采样对比正常情况与异常情况的采样，表面现象为计算开销增加，在代码路径上没有看出其他异常。 GraalVM EE 现象偶发现象：CPU us 特别高，sy 较低。退出压测进程重新运行后现象消失。6 节点测试中，该现象频繁出现GraalVM 发生该现象时对性能影响非常明显，tpmC 相比正常几乎减半。

1.简介别名分析是编译器理论中的一种技术，用于确定存储位置是否可以以多种方式访问。如果两个指针指向相同的位置，则称这两个指针为别名。 但是，它不能与指针分析混淆，指针分析解决的问题是一个指针可能指向哪些对象或者指向哪些地址，而别名分析解决的是两个指针指向的是否是同一个对象。指针分析和别名分析通常通过静态代码分析来实现。别名分析在编译器理论中非常重要，在代码优化和安全方面有着非常广泛且重要的应用。编译器级优化需要指针别名信息来执行死代码消除（删除不影响程序结果的代码）、冗余加载/存储指令消除、指令调度（重排列指令）等。编译器级别的程序安全使用别名分析来检测内存泄漏和内存相关的安全漏洞。2.别名分析分类别名分析种类繁多，通常按如下属性进行分类：域敏感（field-sensitivity）、过程内分析（Intra-Procedural）v.s.过程间分析（Inter-Procedural）、上下文敏感度（context-sensitivity）和流敏感度（flow-sensitivity）。2.1 域敏感（Field-Sensitivity）域敏感是对用户自定义类型进行分析的一种策略（亦可以处理数组）。在域敏感维度共有三种分析策略：域敏感（field-sensitive）、域非敏感（field-insensitive）、域基础分析（field-based）。以下面代码为例：struct Test { int field1; int field2; } Test a1; Test a2;Note：field这里为结构体或者类的数据成员。域非敏感：对每个对象建模，而对对象中的成员不进行处理；其建模后的结果如下图，仅有a1.*和a2.*的区别：域基础分析：仅对结构体中的成员进行建模，而不感知对象。其建模后的结果如下图，仅有*.field1和*.field2：域敏感：既对对象建模，又对成员变量进行处理。其建模后的结果如下图，有a1.field1、a1.field2、a2.field1、a2.field2：处理数组时，相同的原则亦适用。以C整数数组为例：int a[10]，域非敏感分析仅使用一个节点建模：a[*]，而域敏感分析创建10个节点：a[0]、a[1]、...、a[9]。总结：域敏感别名分析准确性高，但是当存在嵌套结构或者大数组时，节点数量会迅速增加，分析成本也会陡然上升。2.2 过程内分析（Intra-Procedural）v.s.过程间分析（Inter-Procedural）过程内分析仅分析函数体内部的指针，并没有考虑与其他函数之间的相互影响。需要特别指出的是，过程内分析当处理包含指针入参的函数或者返回指针的函数时，其分析可能不够准确。相反，过程间分析会在函数调用过程中处理指针的行为。过程内分析不易于扩展，精度较低。相比过程间分析，过程内分析更容易实现，且过程内/间分析与上下文敏感度分析高度相关，因为一个上下文敏感分析必定是一个过程间分析。2.3 上下文敏感度（Context-Sensitivity）上下文敏感度用来控制函数调用该如何分析。有两种分析方法：上下文敏感（context-sensitive） 和上下文非敏感（context-insensitive）。上下文敏感在分析函数调用的目标（被调用者）时考虑调用上下文（调用者）。以如下代码为参考[1]：1  public static void main(String[] args) { 2      String name1 = getName(3);  // Tainted 3      String sql1 = "select * from user where name = " + name1; 4      sqlExecute(sql1);  // Taint Sink 5      6      String name2 = getName(-1);  // Not Tainted 7      String sql2 = "select * from user where name = " + name2; 8      sqlExecute(sql2); 9  } 10  11  private static String getName(int x) { 12     if (x > 0) { 13          return System.getProperty("name"); 14      } else { 15          return "zhangsan"; 16      } 17  }如上所示，getName()方法基于入参的不同，会返回不同的结果，在第2行和第6行，获取到的name1和name2的污点信息不同，当入参为3时，返回的是一个从环境变量中获取的污染的数据，导致sql注入，而当入参为-1时，返回的是一个常量，不是污染数据，不会有问题。 在上下文敏感的分析中，在第4行应该报一个sql注入问题，而在第8行则不应该报sql注入问题。而上下文非敏感的分析中，不考虑传入参数的不同，getName()方法则全部返回一个{System.getProperty("name")}∨{zhangsan}，从而导致第4行和第8行都会报一个sql注入的问题。上下文敏感别名分析需要有一种方法，为函数getName创建抽象描述，以便每次调用它时，分析器都可以将调用上下文应用于抽象描述。总结：上下文敏感分析比较准确，但是增加了复杂度。2.4 流敏感度Flow-Sensitivity流敏感度是一种是否考虑代码顺序的原则。有两种方法：流敏感（flow-sensitive）和流非敏感（flow-insensitive）。流非敏感不考虑代码顺序，并为整个程序生成一组别名分析结果，而流敏感考虑代码顺序，计算程序中每个指针出现的位置的别名信息。以如下代码为例：1   int a,b; 2   int *p; 3   p = &a; 4   p = &b;流非敏感的分析结果是针对整个代码块，其结果应该是：指针p可能指向变量a或者变量b。流敏感生成的别名信息是，在第3行，指针p指向变量a，在第4行以后指针p指向变量b。Note：当程序具有许多条件语句、循环或递归函数时，流敏感分析的复杂性会大大增加。要执行流敏感分析，需要完整的控制流图。因此，流敏感分析非常精确，但对于大多数情况来说，它的分析成本过高，无法在整个程序上执行。3.别名分析常见算法介绍常见的别名算法共有三种：Andersen's指针分析算法、Steensgaard's指针分析算法和数据结构分析算法。Andersen's指针分析是一种流非敏感和上下文非敏感的分析算法。Andersen's指针分析算法复杂度较高，实践应用性较差，其时间复杂度为，其中n为指针节点个数。Steensgaard's指针分析算法也是一种流非敏感，上下文非敏感且域非敏感的别名分析算法。其时间复杂度较低，实现相对简单，实践应用广，其时间复杂度为，其中无限接近于1，但是其别名分析的准确性较低。数据结构分析算法是一种流非敏感，上下文敏感和域敏感的算法。其时间复杂度较低，为O(n * log(n)) ，应用性较好，但是由于不支持MustAlias（参考“AliasAnalysis Class概览”章节），导致其应用有局限性。4.别名分析在LLVM中的应用与实现4.1 应用别名分析在代码优化和安全方面有着非常重要且广泛的应用，以下面C代码为例，来简单介绍别名分析在代码优化方面的应用[2]。int foo (int __attribute__((address_space(0)))* a,          int __attribute__((address_space(1)))* b) {     *a = 42;     *b = 20;     return *a; }__attribute__属性指定了变量a指向地址0，变量b指向地址1。我们知道在ARM架构中，地址0和地址1是完全不同的，修改地址0中的内存永远不会修改地址1中的内存。以下为该函数可能生成的LLVM IR信息：define i32 @foo(i32 addrspace(0)* %a, i32 addrspace(1)* %b) #0 { entry:   store i32 42, i32 addrspace(0)* %a, align 4   store i32 20, i32 addrspace(1)* %b, align 4   %0 = load i32, i32* %a, align 4   ret i32 %0 }第一个store将42存储到变量a指向的地址，第二个store指令将20存储到变量b指向的地址。%0 = ... 指向的行将变量a中的值加载到一个临时变量0中，并在最后一行返回该临时变量0。上述代码是未对foo函数进行优化的情况，下面我们考虑对foo函数进行优化。我们优化后的代码可能如下：删除了load指令对应的行，最后一行直接返回了常量42。define i32 @foo(i32 addrspace(0)* %a, i32 addrspace(1)* %b) #0 { entry:   store i32 42, i32 addrspace(0)* %a, align 4   store i32 20, i32 addrspace(1)* %b, align 4   ret i32 42 }然而，我们进行优化的时候需要仔细一些，因为上述优化仅在a和b指向的地址不会相互影响时有效。例如：当我们给foo函数传递的指针相互影响时：int i = 0; int result = foo(&i, &i);在未开启优化的版本中，变量i将先被设置为42，然后被设置为20，最后返回20。然而，在优化版本中，虽然我们执行了两次store操作依次将42、20赋值给变量i，但是返回值是42，而不是20。因此优化版本破坏了foo函数本身的行为。如果应用了别名分析，编译器能够合理的执行上述优化。在执行优化前判断入参a和b是否为别名，如果是别名，则不执行删除load指令对应行的操作，否则执行删除操作。4.2 实现本文以LLVM16.0.0版本为参考，从代码接口入手，带领大家学习别名分析的代码实现。LLVM AliasAnalysis类是LLVM系统中客户使用和别名分析实现的主要接口，或者说一个“基类” 。除了简单的别名分析信息外，这个类还声明了Mod/Ref信息，从而使强大的分析和转换能够很好地协同工作。源码参考链接：AliasAnalysis.h[3]、AliasAnalysis.cpp[4]。4.2.1 基础知识MemoryLocation：LLVM中对内存地址的描述，主要应用在别名分析中，我们需要掌握该类中三个属性：其中，Ptr表示内存开始地址，Size表示内存大小，AATags是描述内存位置别名的metadata节点集合 。4.2.2 AliasAnalysis Class 概览AliasAnalysis类定义了各种别名分析实现应该支持的接口。这个类导出两个重要的枚举:AliasResult和ModRefResult，它们分别表示别名查询或mod/ref查询的结果。1、关键代码如下，AliasAnalysis为AAResults类别名：2、AliasResult关键代码如下：其中NoAlias表示两个内存对象没有任何重叠区域；MayAlias表示两个指针可能指向同一对象；PartialAlias表示两个内存对象对应的地址空间有重叠；MustAlias表示两个内存对象总是从同一位置开始。3、ModRefResult关键代码其中NoModRef表示访问内存的操作既不会修改该内存也不会引用该内存； Ref表示访问内存的操作会可能引用该内存；Mod表示访问内存的操作可能会修改该内存；ModRef表示访问内存的操作既可能引用该内存也可能修改该内存。alias接口其接口定义如下：别名方法是用于确定两个MemoryLocation对象是否相互别名的主要接口。它接受两个MemoryLocation对象作为输入，并根据需要返回MustAlias、PartialAlias、MayAlias或NoAlias。 与所有AliasAnalysis接口一样，alias方法要求其入参的两个MemoryLocation对象定义在同一个函数中，或者至少有一个值是常量。其接口实现如下：getModRefInfo 接口getModReInfo方法返回关于给定的指令执行是否可以读取或修改给定内存位置的信息。Mod/Ref信息具有保守性：如果一条指令可能读或写一个位置，则返回ModRef。 其接口定义众多，我们以如下接口为例来进行学习。其接口实现如下：从上述代码可知，处理共分为四步：（1）遍历AAs，如果发现其任一结果是NoModRef，则直接返回，对应代码行228-234；（2）调用节点（call）操作中是否访问了一个在LLVM IR中无法访问的地址，如果是的话，直接返回NoModRef，否则获取其调用节点的ModRefInfo信息，对应代码行239-240；（3）处理调用节点中指针入参的ModRefInfo信息，如果发现是NoModRef，则直接返回NoModRef，否则将ModRefInfo信息和之前的结果合并，对应代码行247-266；（4）如果getModRefInfo函数中的入参Loc指定的内存地址具有常量属性并且ModRefInfo信息包含Mod，则调用节点一定不会修改Loc内存，因此需要将Ref属于与之前的结果做逻辑与操作，对应代码行271-272。4.2.3 LLVM中已经实现的别名分析-basic-aa pass-basic-aa pass是一种激进的本地分析，它提供许多重要的事实信息[5]：不同的全局变量、堆栈分配和堆分配永远不能别名。全局变量、栈分配的变量和堆分配变量永远不会和空指针别名。结构体中的不同字段不能别名。同一数组，索引不同的两个对象不能别名。许多通用的标准C库函数从不访问内存或只读取内存。-globals-aa pass这个pass实现了一个简单的对内部全局变量（该变量的地址没有被获取过）进行上下文敏感的mod/ref分析和别名分析。 如果某个全局变量的地址没有被获取，则该pass可以得出如下结论：没有指针作为该全局变量的别名。该pass还会识别从不访问内存或从不读取内存的函数。这允许某些指定的优化(例如GVN)完全消除调用指令。这个pass的真正威力在于它为调用指令提供了上下文敏感的mod/ref信息。这使优化器清楚的了解到对于某些函数的调用不会破坏或读取全局变量的值，从而允许消除加载和存储指令。Note：该pass在使用范围上有一定限制，仅支持没有被取过地址的全局变量，但是该pass分析速度非常快。除了上述pass外，LLVM中还实现了cfl-steens-aa、cfl-anders-aa、tbaa、scev-aa。目前LLVM中O1，O2，O3优化默认开启的别名分析是basic-aa，globals-aa和tb-aa。5.写在最后编译器技术从20世纪50年代起，已经发展了近70年的历史，但是编译器技术发展到今天，依然是一个非常热门的技术，各大硬件厂商都在开发自己的编译器，包括因特尔推出的Inter C++、ARM公司推出的armclang以及华为推出的毕昇编译器等，且上述三款编译器都是基于LLVM开发。编译器技术是一门庞大且繁杂的技术，对于初学者来说，这条学习之路道阻且长，盼那些热爱这门技术的赶路人能够行而不辍，未来可期。参考[1]cid:link_3[2]cid:link_2[3]cid:link_1[4]cid:link_0[5]cid:link_4后记欢迎加入Compiler SIG交流群与大家共同交流学习编译技术相关内容，扫码添加小助手微信邀请你进入Compiler SIG交流群。

鲲鹏软件性能调优学习笔记 在鲲鹏社区的鲲鹏软件性能调优实践微认证课程中，我主要学习了鲲鹏软件性能调优机制，了解和掌握了如何根据硬件特点进行性能调优，以及项目中性能调优的基本思路和常用性能采集工具。性能调优的本质是充分发挥硬件的性能，而通过软硬协同可以带来万倍的代码性能提升。从冯诺依曼计算机体系结构来看，性能的优化可以从四个层面来进行探讨，即CPU/内存、磁盘、网卡和应用。 1. 在CPU/内存层面基于鲲鹏处理器的加速可以分为软加速和硬加速。软加速又分为针对单核的单核加速和针对多核的多核加速。基于鲲鹏芯片微架构的编译器性能优化主要包括了指令布局优化、内存布局优化和循环优化。JDK性能优化主要包括序列化、JVM循环、JIT优化、GC优化和向量化等。在SMP系统中，核数的扩展受到内存总线的限制，可以采用非统一内存访问架构（ Non-uniform memory access）解决这一问题。发挥NUMA性能，需要克服内存访问速度不均匀的挑战。利用CPU亲和性与内存分配策略，让进程与内存的距离更“短”。基于鲲鹏技术优势构建的加速库，针对基础、压缩、加解密和多媒体四类业务提供9大加速库，实现典型场景10%-100%性能提升。此外，鲲鹏RSA加密加速方案，相较于传统方案可以有效提升Web应用Https性能。2. 在磁盘层面文件系统决定了磁盘加载到内存过程的快慢。磁盘预取可以充分利用磁盘带宽。3. 在网卡层面网卡中断产生频率会影响应用的吞吐和延迟。具体而言，中断产生的频率高会消耗大量的CPU时间片，频率低会影响应用收到数据的时延。可以通过调整网卡中断聚合，在低时延和高吞吐中取一个平衡点。降低网卡中断频率，可以带来约10%的吞吐提升，但也会造增加20%左右的延迟。4. 在应用层面软件调优的本质是充分发挥硬件性能。减少资源抢占，提升并行度，发挥多核性能优势。Tcmalloc使用线程缓存，尺寸小于256K的小内存申请均由ThreadCache进行分配；通过ThreadCache分配过程中不需要任何锁，可以极大的提高分配速度。总结：鲲鹏软件性能调优主要通过以下手段实现。

玩转PB级分布式数仓GaussDB(DWS)性能调优黑科技玩转PB级数仓深度调优之依“计”行事

本讲为您介绍华为云数仓GaussDB(DWS) 调优的基本理论、常见的SQL性能问题的定位手段和解决方案

前言关于单点性能调优的帖子很多，这里从基础理论、实战演练、现网案例三个维度汇总单点性能调优的方法基础理论analyze统计信息https://bbs.huaweicloud.com/blogs/192029explain计划信息https://bbs.huaweicloud.com/blogs/197945分布式计划详解https://bbs.huaweicloud.com/blogs/200449实战演练总体调优策略https://bbs.huaweicloud.com/blogs/200906味道SQL识别https://bbs.huaweicloud.com/blogs/197413好味道表定义https://bbs.huaweicloud.com/blogs/203219SQL改写https://bbs.huaweicloud.com/blogs/203420路径干预https://bbs.huaweicloud.com/blogs/212459Plan hint运用https://bbs.huaweicloud.com/blogs/213195现网案例单点性能案例集锦https://bbs.huaweicloud.com/forum/thread-90331-1-1.html

【功能模块】用VSCode 安装性能分析工具报空间不足安装过程：【操作步骤&问题现象】报错：请帮忙查看该问题【日志信息】（可选，上传日志内容或者附件）

【操作步骤&问题现象】1、添加采样分析报错，且采样状态卡死【截图信息】

【操作步骤&问题现象】1、连接目标环境 非root账户 报联系管理2、具体需要那个写文件权限【截图信息】

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 如何配置这个参数，可以达到速度最优？