性能优化是降低成本的手段之一,每年大促前业务平台都会组织核心链路上的应用做性能优化,一方面提升系统性能,另外一方面对腐化的代码进行清理。本文结合业务平台性能优化的经验,探讨一下性能优化的思路及常用工具及手段。性能优化是降低成本的手段之一,每年大促前业务平台都会组织核心链路上的应用做性能优化,一方面提升系统性能,另外一方面对腐化的代码进行清理。现结合业务平台性能优化的经验,探讨一下性能优化的思路及常用工具及手段。性能优化本质上是对资源的合理利用,将更珍贵的资源用在更重要的业务上,从而实现资源的充分利用,资源的合理利用。性能优化的对象包括业务运行的容器、业务依赖的中间件、业务依赖的数据库存储的优化,性能优化包括两部分:一、发现需要性能优化的点;二、改造代码设计实现性能优化;对于业务容器来说,需要性能优化的点,往往是对系统开销最大的业务方法,这部分代码功能上并没有任何问题,但在性能上并不是最优,在资源比较充足的情况下,这部分逻辑并不会导致性能问题,但当系统压力比较大,或者业务流量比较高的情况下,这部分就会成为压力最大的点。将流量在部分容器上做放大,利用工具采集系统中的堆栈及性能数据。放大系统流量的情况下,需要提前关闭应用及容器的限流,可以利用Sentinel脚本调整。
curl http://localhost:8719/switchSet?value=false
curl http://localhost:8718/setSwitch?value=false
一、Duct引流验证
Duct引流, duct调整某一台机器的CS权重,将其他容器的流量引流到对应的ip上,从而实现压力的放大。
Amazon压测,根据特定的业务场景,构造压测压测数据,压测模型,在gray4环境中打一部分压测流量,利用压测流量将系统的负载打高。Amazon更适用于大促场景下的性能优化,能确定某些接口的比例,及场景的比例。系统负载流量增加后,各个环节的系统性能消耗都会被放大,此时利用工具可以分析系统的性能情况。系统分析工具会带来系统压力增加,非必要情况下,尽量在隔离环境统计数据。Arthas性能数据采集
Arthas提供了非常多的工具脚本,其中一部分数据组合起来使用,可以很方便的辅助做性能分析及线上问题排查,这里对其中常用的指令及使用场景做汇总。安装方式:curl -sLk http://ops.jm.taobao.org:9999/pandora-web/arthas/install.sh | sh | | |
| 查看当前JVM下ClassLoader的列表及加载的实例统计信息 | - 常见于排查Metaspace空间利用率问题,常见的场景是由于Groovy脚本导致的Metaspace增加,进而导致应用FGC的问题排查
|
| | - 常见于黑盒分析,无法快速活的源码的情况下分析程序内部逻辑的场景
|
| | - 常见于分析开关、配置、部分数据的情况,在分析性能数据时可以辅助排查
|
| | - 常见于分析热点方法调用来源,结合条件过滤,可以快速定位到异常数据产生的来源以及调用频率
|
| | - 常见于分析耗时情况,分析某一个方法耗时的原因。比如分析鹰眼某一个接口耗时很高的原因
|
| | - 分析线上方法的入参及返回值,结合条件判断,可以快速知道某一个函数可能走到的场景
|
| | |
| | |
| 内部使用了Async Profiler工具,可以用来采集内存、cpu、锁、cache miss等火焰图数据 | - 启动分析,分析应用启动速度慢的原因,并行化,锁等场景
- 内存分配分析,分析JVM应用Old区增长较快的原因
|
| | - 获取jvm中某些类的实例列表,进而利用其他指令分析内部的数据
|
| | - 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
天巡数据采集性能数据
工具地址: https://explorer.alibaba-inc.com/perf/#/profile注意: 指标采集功能从实现上基本都是在运行的JVM进程上挂载agent,随后对部分代码进行增强及注入,会引起类的退优化及C2编译,本身会导致程序的CPU增高,对于性能的采集不能在系统高负载的情况下执行。必要时在仿真环境里执行。 | | |
| 内核火焰图,统计内存分配的情况,利用统计TLAB中的内存分配 | |
| | - 性能分析,统计系统性能衰减的原因,分析消耗cpu的点以及执行频率高的代码段
|
| 线程分布分析,将线程堆栈制作成火焰图形式,方便分析 | |
| jprofiler的快照采集,利用关在agent数据,采集1分钟的CPU快照 | - 性能分析,类似CPU火焰图,但可以利用Jprofiler的图形化界面,进行对比分析
|
| 利用JDK提供的jcmd dump jvm的metaspace数据 | |
| 利用perf-map-agent生成jvm的符号表,利用Linux自带的Perf工具分析系统的性能数据,结合flame-graph可以生成类似的火焰图 | |
黑屏场景下的性能分析
特殊的环境下,可能无法使用配套的工具,此时应尽量利用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.gzsudo yum -y install perf
sh create-java-perf-map.sh
sudo perf record -ag
sudo perf report
图1.4 利用Perf结合perf-map-agent 分析高CPU消耗数据分析应用在启动过程中,应用运行的堆栈,进而分析出启动过程中,应用执行耗时最多的热点代码,进而针对性的做启动优化$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区的引用)。
|
| - 常见与大型的项目中,代码共建性,循环的调用,重复的初始化,重复的数据统计等带来的性能开销。
- 此时合理利用上下文缓存,对象缓存,能够显著降低系统性能开销
|
| - 字符串的匹配、正则等均为消耗性能比较大的代码,热点代码中应尽量少用
- 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机型等。不同的机型单核性能上表现会有差异。 | | |
| | 4代机型,性能较差,主要分布在日常环境,cpu频率在2.5GHZ左右。 |
| 5代机型,不带神龙Moc卡,使用本地盘,性能比F4x好,主要集中在mix25g |
| |
| 倚天机型,主要在南通部署,FY24张北也会做部署。JDK8上单核性能弱于JDK11, JDK11上单核略弱于F6x |
二、由于编排方式带来的性能差异
在X86架构下,由于超线程的存在,业务容器实际使用的是物理核心上的超线程,当一个8C16G的容器独占8个物理核的时候,性能会最好。当8C16G的容器占用4个物理核的时候,性能会相对最差。结合跨Numa、跨socket等编排方式,也会带来性能的差异。 | |
8C16G容器,独占使用同一个Socket上的8个物理核(P4-P11 未编排容器) | |
8C16G容器,独占使用跨Socket上的8个物理核(P20 - P28) | Socket可以简单对应到主板上的Cpu插槽,跨soeck后,会导致Cpu之间跨socket访问内存及cache,性能相比前一种场景要差,具体差异还和应用特性有关,大内存带宽的应用性能会相对更差 |
8C16G容器,使用同一个Socket上的8个超线程,物理核对端被其他应用占用 | 由于超线程之间会存在L1、L2cache的共享,两个超线程之间会存在资源争抢,此时性能也会受到影响 |
8C16G容器,使用同一个socket上的4个物理核 | 此时应用的表现比较稳定,不会收到外部性能的差异产生影响。一般情况下性能表现最差,但比较确定 |
数据库慢查询的优化
数据库侧的性能问题,主要有以下集中情况导致,常见的优化手段为:一、合理利用前置的缓存,降低对数据库的访问量。缓存从效率及成本上都优于数据库。二、清理数据库中的数据,对过期的数据、访问量少的冷数据进行清理及迁移。降低数据库的存储大小,对在线的查询会有帮助,对离线的存储、引擎、缓存等场景也会有收益。三、合理调整索引,结合业务场景丰富查询条件,提高数据库的执行效率。四、利用数据库聚合特性,调整主键的组成,提高数据的聚合度,降低逻辑读。 | |
| - 如果是查询请求,可以适当的利用缓存,降低数据库的压力,和数据库相比,缓存的效率更高,成本更低
- 如果是写请求,评估业务的合理性,是否能降低业务请求的频率,不如通过限速、削峰的方式降低数据库的压力
|
| - 结合业务场景适当增加SQL条件,让SQL走到先存的索引上
|
走到索引,但是召回数据量过大,导致的SQL执行效率低 | |
| |
缓存类优化(Tair、Redis)
缓存类存储对随机的访问上效率上都非常高,在日常及大促的核心场景中发挥比较大的作用。缓存类常见的问题: | |
| - 分析调用的合理性,适当使用前置缓存进行拦截(IC、UIC的前置缓存)
|
| - 典型的热点场景,一般热点场景客户端可以增加对热点的缓存,降低整体的qps。
- 对于Tair 也可以利用tair自身的Hotzone来进行处理
|
| - 写Qps大的场景,需要对key进行拆分,让单个key的写hash到不同的ds上,分摊压力。
|
个别Key的读QPS量级大,而且单key的也比较大 | - 一方面按照热点key进行处理,另外一方面需要对大key进行拆分
- 大key会带来带宽打满,对于tair来说表现为带宽限流
- 对于Redis,在slb、poxy、ds层均有可能被打满,紧急情况下有限扩容。
|
应用间链路依赖,一般是在单应用容量优化完成后,从整个链路上考察,优化链路的RT及链路的CPU开销。一般应用链路的优化,需要结合应用链路分析来考虑,这里主要利用鹰眼的数据进行分析。 | |
| - 一般情况下是由于链路上某一个环节存在调用放大导致,且后续的调用会同步执行导致RT增加
- 性能考虑, 评估是否能降低调用量的方式(重复调用,模型合理性等)
|
| - 适当精简链路上Module对象的字段,减少传输数据的大小。
|
不合理的调用链路(A-B-C) --> (A-C) | - 精简链路,减少不必要的代理调用(ump2直连Fp2的数据库)
|
Q:例如ASI排查场景中,看到pod cpu高 或者 load高,但根因是出在其他地方,可能是安全插件rasp负载高、也可能是后台异常内存回收、也可能是宿主机负载高导致,现在全凭经验做排除法,有没有类似字典的方式手段定位问题?A:一般情况下出现这种情况,可以从几个角度缩小问题产生的范围。1)是不是该宿主机上的所有容器都有类似的表现?如果所有容器都有类似的表现,那基本上是宿主机的问题,可能是由于离线导致,可能是由于内存回收,可能是由于部分agent导致,此时case by case分析,也可以让TRE团队协助分析。2)如果宿主机上只有本容器出现问题,大概率是本容器自身的问题,此时可以从几个角度入手:Q:平台中使用到了云平台中相关的中间件比如Kafka、Redis等,由于平台运行环境(Daily、PPE、Online)不同最少需要申请两个实例,一个Daily实例和Online实例。Online环境申请的规格是最低配置就可以满足,同时Daily环境中平台流量很小所以最低规格配置就大大浪费了,但是云平台又不支持更小规格配置申请,能否和云平台的同事沟通下此类问题。A:弹内一般情况下,数据库节点、缓存节点实际规格非常小,成本相对比较低。如果对成本有更进一步的诉求,可以考虑多业务公用的方式,一般情况下日常的存储及QPS量级均非常小,若干个业务共用同一套存储不会带来太大的问题,对于缓存需要重点考虑的就是隔离的问题,这部分可以通过工具方式解决。你时常焦虑吗?一般是在什么场景,工作或生活?我们是否掉入了“别人贩卖的焦虑”(PUA、35岁危机)的陷阱?
点击阅读原文参加话题讨论,截止2024年1月14日24时,我们将会选出 2 名幸运用户和 2 个优质回答分别获得阿里云开发者无线充电器一个。