阿里妹导读

性能优化是降低成本的手段之一，每年大促前业务平台都会组织核心链路上的应用做性能优化，一方面提升系统性能，另外一方面对腐化的代码进行清理。本文结合业务平台性能优化的经验，探讨一下性能优化的思路及常用工具及手段。

性能优化是降低成本的手段之一，每年大促前业务平台都会组织核心链路上的应用做性能优化，一方面提升系统性能，另外一方面对腐化的代码进行清理。现结合业务平台性能优化的经验，探讨一下性能优化的思路及常用工具及手段。性能优化本质上是对资源的合理利用，将更珍贵的资源用在更重要的业务上，从而实现资源的充分利用，资源的合理利用。性能优化的对象包括业务运行的容器、业务依赖的中间件、业务依赖的数据库存储的优化，性能优化包括两部分：一、发现需要性能优化的点；二、改造代码设计实现性能优化；

• CPU的开销，有限的cpu无法支撑更大的业务 （性能问题）
• CPU利用不充分，有限的CPU，无法更好的支撑业务（RT问题）

一、发现需要性能优化的点

对于业务容器来说，需要性能优化的点，往往是对系统开销最大的业务方法，这部分代码功能上并没有任何问题，但在性能上并不是最优，在资源比较充足的情况下，这部分逻辑并不会导致性能问题，但当系统压力比较大，或者业务流量比较高的情况下，这部分就会成为压力最大的点。

1） 放大系统的流量

将流量在部分容器上做放大，利用工具采集系统中的堆栈及性能数据。放大系统流量的情况下，需要提前关闭应用及容器的限流，可以利用Sentinel脚本调整。

### 取消限流 2.X 
curl http://localhost:8719/switchSet?value=false 

### 取消限流 3.X 
curl http://localhost:8718/setSwitch?value=false 

一、Duct引流验证

Duct引流， duct调整某一台机器的CS权重，将其他容器的流量引流到对应的ip上，从而实现压力的放大。

二、Amazon构造压测数据验证

Amazon压测，根据特定的业务场景，构造压测压测数据，压测模型，在gray4环境中打一部分压测流量，利用压测流量将系统的负载打高。Amazon更适用于大促场景下的性能优化，能确定某些接口的比例，及场景的比例。

2) 利用工具采集系统热点

系统负载流量增加后，各个环节的系统性能消耗都会被放大，此时利用工具可以分析系统的性能情况。系统分析工具会带来系统压力增加，非必要情况下，尽量在隔离环境统计数据。

Arthas性能数据采集

Arthas提供了非常多的工具脚本，其中一部分数据组合起来使用，可以很方便的辅助做性能分析及线上问题排查，这里对其中常用的指令及使用场景做汇总。

安装方式：curl -sLk http://ops.jm.taobao.org:9999/pandora-web/arthas/install.sh | sh

图 1.1 Arthas指令集合列表

性能分析及问题分析工具说明

指令	说明	性能分析及问题排查的场景
classloader	查看当前JVM下ClassLoader的列表及加载的实例统计信息	* 常见于排查Metaspace空间利用率问题，常见的场景是由于Groovy脚本导致的Metaspace增加，进而导致应用FGC的问题排查
jad	反编译	* 常见于黑盒分析，无法快速活的源码的情况下分析程序内部逻辑的场景
getstatic	获取静态字段的值	* 常见于分析开关、配置、部分数据的情况，在分析性能数据时可以辅助排查
stack	从当前方法点打印堆栈	* 常见于分析热点方法调用来源，结合条件过滤，可以快速定位到异常数据产生的来源以及调用频率
trace	从当前方法下钻	* 常见于分析耗时情况，分析某一个方法耗时的原因。比如分析鹰眼某一个接口耗时很高的原因
watch	查看方法调用的参数及返回值	* 分析线上方法的入参及返回值，结合条件判断，可以快速知道某一个函数可能走到的场景
options	Arthas的一些选项	* 在需要分析jdk内部的调用时，可以打开某些选项
logger	打印日志相关的信息	* 分析日志冲突，临时关闭某些日志场景等
profiler	内部使用了Async Profiler工具，可以用来采集内存、cpu、锁、cache miss等火焰图数据	性能分析，分析当前业务的热点方法 启动分析，分析应用启动速度慢的原因，并行化，锁等场景 * 内存分配分析，分析JVM应用Old区增长较快的原因
vmtool	获取实例 强制GC	获取jvm中某些类的实例列表，进而利用其他指令分析内部的数据 强制应用做GC
jfr	jfr数据采集	* jfr快照分析，可以快速分析整个JVM的运行情况。

场景一、CPU资源开销分析

利用profiler指令采集应用容器的性能，profiler start 默认采集的CPU的数据， profiler stop 自动dump对应的文件数据。

[arthas@2093]$ profiler start 
Profiling started 
[arthas@2093]$ profiler stop 
OK 
profiler output file: /home/admin/ump2/bin/arthas-output/20230213-191902.html 
[arthas@2093]$ exit 

场景二、JVM内存中分配了比较多的对象，但很快回收，希望找到临时对象创建比较频繁的堆栈。

[arthas@2093]$ profiler -e alloc start 
Profiling started 
[arthas@2093]$ profiler stop 
OK 
profiler output file: /home/admin/ump2/bin/arthas-output/20230213-192148.html 
[arthas@2093]$ exit 

场景三、应用启动速度比较慢，希望找到原因。

[arthas@2093]$ profiler start -e wall 
Profiling started 
[arthas@2093]$ profiler stop 
OK 
profiler output file: /home/admin/ump2/bin/arthas-output/20230213-192812.html 
[arthas@2093]$ 

场景四、利用JFR分析JVM整体的运行情况，采集数据用作分析。

[arthas@82348]$ jfr start -n test 
[arthas@82348]$ jfr stop -r 1 -f /tmp/1.jfr 
Stop recording 1, The result will be written to: 
/tmp/1.jfr 

图1.2 JFR数据示例

天巡数据采集性能数据

工具地址： https://explorer.alibaba-inc.com/perf/#/profile

图1.3 天巡白屏化采集性能数据

天巡功能采集指标说明

注意： 指标采集功能从实现上基本都是在运行的JVM进程上挂载agent，随后对部分代码进行增强及注入，会引起类的退优化及C2编译，本身会导致程序的CPU增高，对于性能的采集不能在系统高负载的情况下执行。必要时在仿真环境里执行。

诊断项	功能说明	使用场景
内存火焰图	内核火焰图，统计内存分配的情况，利用统计TLAB中的内存分配	临时对象产生过快，分析产生的原因 应用FGC间隔断，old区上涨曲线陡峭
CPU火焰图	对CPU消耗进行采样，统计代码的热度及调用堆栈	性能分析，统计系统性能衰减的原因，分析消耗cpu的点以及执行频率高的代码段 Buy2 CPU数据分析示例
线程火焰图	线程分布分析，将线程堆栈制作成火焰图形式，方便分析	* 分析线程热度及死锁
jprofiler	jprofiler的快照采集，利用关在agent数据，采集1分钟的CPU快照	性能分析，类似CPU火焰图，但可以利用Jprofiler的图形化界面，进行对比分析 Buy2性能数据Jprofiler快照
Metaspace	利用JDK提供的jcmd dump jvm的metaspace数据	分析jvm的metaspace的占用情况 统计出metaspace 占用较高的原因
Perf	利用perf-map-agent生成jvm的符号表，利用Linux自带的Perf工具分析系统的性能数据，结合flame-graph可以生成类似的火焰图	* 性能分析，用于分析内核态、用户态、JVM数据功能

黑屏场景下的性能分析

特殊的环境下，可能无法使用配套的工具，此时应尽量利用JVM及Linux系统中自带的工具，采集数据后，在本地利用工具进行数据分析。

一、利用Perf分析系统性能，Perf是linux内核提供的性能分析工具，利用该工具可以很方便的分析整机的性能数据

CPU消耗来自非Java程序的场景，或者希望结合Java程序整体分析系统情况的场景📎perf-map-agent.compiled.tgz：https://yuque.antfin.com/attachments/lark/0/2024/gz/8526/1704162543426-7fcb3be9-4465-475e-8518-4cf6449ca3c8.gz

sudo yum -y install perf 
sh create-java-perf-map.sh 
# 采集性能数据 
sudo perf record -ag  
# 分析性能数据 
sudo perf report 

图1.4 利用Perf结合perf-map-agent 分析高CPU消耗数据

二、利用jstack分析应用的启动情况

分析应用在启动过程中，应用运行的堆栈，进而分析出启动过程中，应用执行耗时最多的热点代码，进而针对性的做启动优化

$cat 1.sh 
for i in `seq 10000` 
do 

  /opt/taobao/java/bin/jstack $1 > /tmp/$1.$i.log 

done 

三、利用jmap、jcmd dump数据，相关数据dump出来后，可以进一步通过工具进行分析

/opt/taobao/java/bin/jcmd 82348 help 
/opt/taobao/java/bin/jcmd 82348 help CodeCache.dump 
/opt/taobao/java/bin/jcmd 82348 help Compiler.CodeHeap_Analytics 
/opt/taobao/java/bin/jcmd 82348 JVMTI.data_dump 
/opt/taobao/java/bin/jcmd 82348 help Metaspace.dump 
/opt/taobao/java/bin/jmap -dump:format=b,file=/tmp/heap.bin 82348 

图1.5 jcmd 分析CodeCache的大小及区间数据

二、常见的性能优化点及优化方式

常见的优化点	说明
* 不合理的算法使用，ArrayList 频繁的更新删除，LinkedList 频繁的按照index 获取数据	* 算法及数据结构的误用导致的性能问题
* 大量的日志打印，持续日志打印；日志框架性能的比较，同步Or异步	日志打印会消耗很大的性能，会涉及到内存占用、磁盘IO、锁等待等消耗性能的情况 大量的日志打印，会带来更大的网络开销及存储开销（staragent日志采集、Sls日志存储） * logback > log4j2 > log4j ; 异步打印优于同步打印
* 过程中创建大量的包装类型	包装类型在解决了空和默认值的区别，在小流量场景下可以解决编码复杂性 在一些极端的场景下，类的频繁Box/UnBox会带来相对较多的性能开销
* 使用本地缓存， 年轻代的对象被老年代引用，ygc 耗时增加	本地缓存可以降低远程的数据调用，提高业务的响应RT，是性能优化的一个可选方式 Cms、G1 gc 等分带GC，控制了gc的范围，减少整体GC的频率，但是缓存的频繁更新会带来数据的频繁创建，进而导致ygc耗时的增加（本地缓存会存在old区对young区的引用）。
* 不合理的循环调用，循环内有比较多的高消耗调用	常见与大型的项目中，代码共建性，循环的调用，重复的初始化，重复的数据统计等带来的性能开销。 此时合理利用上下文缓存，对象缓存，能够显著降低系统性能开销
* 字符串的匹配、正则、split相关引入的性能问题	字符串的匹配、正则等均为消耗性能比较大的代码，热点代码中应尽量少用 String.format/String.split 内部均会使用到正则，热点代码尽量少用 * String.isNotBlank/String.isNotEmpty 性能上会有较大的差异。
* 多个条件判断，利用最短路径方式减少压力	业务逻辑上会存在判断比较，从代码风格上，判断逻辑在一起返回会可读性会比较好，但本身会增加计算的复杂度 条件判断应该做到尽早返回，并合理利用最短路径的特点，将尽早返回的条件提前，减少业务开销
* 集合类的自动扩容	jdk中的集合类都会自动扩容，频繁的集合操作，会带来集合的扩容，这部分会带来隐形的资源开销。 利用工具类为集合设置合理的初始大小，避免集合频繁扩容 com.google.common.collect.Maps#newHashMapWithExpectedSize com.google.common.collect.Sets#newHashSetWithExpectedSize
* 热点的计算压力，适当的利用缓存的方式减少系统压力	* 对于热点数据的计算，结合业务合理利用缓存，降低计算的压力。
* 二分查找、hash、bloomfilter、字典树、hyperloglog、bitmap、hashset	合理利用数据结构，解决业务问题。 结合业务数据，降低计算的复杂度。 * 合理的利用其他组件中提供的能力，解决业务问题

三、影响性能的因素

经常会出现同样是8C16G的容器，但表现出来的性能确差异很大，这个在集团内表现尤为明显，这种情况实际和集团内部的编排策略有一定的关系。也可能和集团内部的机型差异存在关系。

一、由于机型原因引起性能差异

目前集团存在多种不同的机型，F4x、F5x、F6x、M机型等。不同的机型单核性能上表现会有差异。

机型	识别方式	性能说明
F4x	cat /proc/cpuinfo 查看CPU型号及频率 F6x 8269CY F5x 8269 F4x E2xxx uname -a 查看Cpu架构 x86_64 X86 * aarch64 倚天机型	4代机型，性能较差，主要分布在日常环境，cpu频率在2.5GHZ左右。
F5x	5代机型，不带神龙Moc卡，使用本地盘，性能比F4x好，主要集中在mix25g
F6x	6代机型，带神龙mock卡，性能比F6x好
倚天	倚天机型，主要在南通部署，FY24张北也会做部署。JDK8上单核性能弱于JDK11， JDK11上单核略弱于F6x

二、由于编排方式带来的性能差异

在X86架构下，由于超线程的存在，业务容器实际使用的是物理核心上的超线程，当一个8C16G的容器独占8个物理核的时候，性能会最好。当8C16G的容器占用4个物理核的时候，性能会相对最差。结合跨Numa、跨socket等编排方式，也会带来性能的差异。

图1.5 应用容器编排示意

编排方式	说明
8C16G容器，独占使用同一个Socket上的8个物理核（P4-P11 未编排容器）	此时容器的性能表现最好，应用独占整个CPU
8C16G容器，独占使用跨Socket上的8个物理核（P20 – P28)	Socket可以简单对应到主板上的Cpu插槽，跨soeck后，会导致Cpu之间跨socket访问内存及cache，性能相比前一种场景要差，具体差异还和应用特性有关，大内存带宽的应用性能会相对更差
8C16G容器，使用同一个Socket上的8个超线程，物理核对端被其他应用占用	由于超线程之间会存在L1、L2cache的共享，两个超线程之间会存在资源争抢，此时性能也会受到影响
8C16G容器，使用同一个socket上的4个物理核	此时应用的表现比较稳定，不会收到外部性能的差异产生影响。一般情况下性能表现最差，但比较确定

四、外部依赖优化

数据库慢查询的优化

数据库侧的性能问题，主要有以下集中情况导致，常见的优化手段为：

一、合理利用前置的缓存，降低对数据库的访问量。缓存从效率及成本上都优于数据库。

二、清理数据库中的数据，对过期的数据、访问量少的冷数据进行清理及迁移。降低数据库的存储大小，对在线的查询会有帮助，对离线的存储、引擎、缓存等场景也会有收益。

三、合理调整索引，结合业务场景丰富查询条件，提高数据库的执行效率。

四、利用数据库聚合特性，调整主键的组成，提高数据的聚合度，降低逻辑读。

场景	优化方案
SQL执行效率高，但调用量大	如果是查询请求，可以适当的利用缓存，降低数据库的压力，和数据库相比，缓存的效率更高，成本更低 如果是写请求，评估业务的合理性，是否能降低业务请求的频率，不如通过限速、削峰的方式降低数据库的压力
索引不合理导致的SQL执行效率低	适当调整索引，让SQL能走到正确的索引上 结合业务场景适当增加SQL条件，让SQL走到先存的索引上
走到索引，但是召回数据量过大，导致的SQL执行效率低	索引区分度不够，索引不合理 适当清理数据，降低逻辑读
走到索引，但时间跨度大，SQL执行效率低	一般是由于数据跨度大，存在冷查询，导致物理读增加 适当清理数据，或者将冷热数据做分离 * 结合业务场景，调整SQL条件，减少数据查询的范围

缓存类优化（Tair、Redis）

缓存类存储对随机的访问上效率上都非常高，在日常及大促的核心场景中发挥比较大的作用。缓存类常见的问题：

问题	说明
缓存的整体qps量级大	* 分析调用的合理性，适当使用前置缓存进行拦截（IC、UIC的前置缓存）
缓存个别key的读qps量级大	典型的热点场景，一般热点场景客户端可以增加对热点的缓存，降低整体的qps。 对于Tair 也可以利用tair自身的Hotzone来进行处理 * 对于Redis可以考虑Proxy层来做优化
个别Key的写Qps量级大	写Qps大的场景，需要对key进行拆分，让单个key的写hash到不同的ds上，分摊压力。 业务侧考虑，能否降低业务写的量级，削峰。
个别Key的读QPS量级大，而且单key的也比较大	一方面按照热点key进行处理，另外一方面需要对大key进行拆分 大key会带来带宽打满，对于tair来说表现为带宽限流 * 对于Redis，在slb、poxy、ds层均有可能被打满，紧急情况下有限扩容。

五、应用链路之间的优化

应用间链路依赖，一般是在单应用容量优化完成后，从整个链路上考察，优化链路的RT及链路的CPU开销。一般应用链路的优化，需要结合应用链路分析来考虑，这里主要利用鹰眼的数据进行分析。

场景	说明
链路调用次数多带来的RT增加	一般情况下是由于链路上某一个环节存在调用放大导致，且后续的调用会同步执行导致RT增加 体验优化，可以考虑适当增加并行化 * 性能考虑， 评估是否能降低调用量的方式（重复调用，模型合理性等）
链路上重复调用带来的序列化开销	结合单机性能分析，评估序列化开销的占比 适当精简链路上Module对象的字段，减少传输数据的大小。
不合理的调用链路（A-B-C) –> (A-C)	* 精简链路，减少不必要的代理调用（ump2直连Fp2的数据库）

图1.6 利用鹰眼查找核心接口上耗时比较大的链路

最后

Q：例如ASI排查场景中，看到pod cpu高 或者 load高，但根因是出在其他地方，可能是安全插件rasp负载高、也可能是后台异常内存回收、也可能是宿主机负载高导致，现在全凭经验做排除法，有没有类似字典的方式手段定位问题？

A：一般情况下出现这种情况，可以从几个角度缩小问题产生的范围。
1）是不是该宿主机上的所有容器都有类似的表现？如果所有容器都有类似的表现，那基本上是宿主机的问题，可能是由于离线导致，可能是由于内存回收，可能是由于部分agent导致，此时case by case分析，也可以让TRE团队协助分析。
2）如果宿主机上只有本容器出现问题，大概率是本容器自身的问题，此时可以从几个角度入手：

• 系统资源开销的分布（sys 高大概率是内核作业相关，irq高大概率是网络包多导致，iowait大概率是文件io比较高导致，单核CPU 100%大概率是gc导致），同时排查资源占用比较高的程序是否是业务程序。
• 针对内核、网络、gc导致的问题，可以进一步case by case 的分析。

Q：平台中使用到了云平台中相关的中间件比如Kafka、Redis等，由于平台运行环境（Daily、PPE、Online）不同最少需要申请两个实例，一个Daily实例和Online实例。Online环境申请的规格是最低配置就可以满足，同时Daily环境中平台流量很小所以最低规格配置就大大浪费了，但是云平台又不支持更小规格配置申请，能否和云平台的同事沟通下此类问题。

A：弹内一般情况下，数据库节点、缓存节点实际规格非常小，成本相对比较低。如果对成本有更进一步的诉求，可以考虑多业务公用的方式，一般情况下日常的存储及QPS量级均非常小，若干个业务共用同一套存储不会带来太大的问题，对于缓存需要重点考虑的就是隔离的问题，这部分可以通过工具方式解决。