模板网站 优帮云,wordpress前台显示中文怎么办,桂林漓江图片高清,提供赣州网站建设性能优化是降低成本的手段之一#xff0c;每年大促前业务平台都会组织核心链路上的应用做性能优化#xff0c;一方面提升系统性能#xff0c;另外一方面对腐化的代码进行清理。现结合业务平台性能优化的经验#xff0c;探讨一下性能优化的思路及常用工具及手段。性能优化本…
性能优化是降低成本的手段之一每年大促前业务平台都会组织核心链路上的应用做性能优化一方面提升系统性能另外一方面对腐化的代码进行清理。现结合业务平台性能优化的经验探讨一下性能优化的思路及常用工具及手段。性能优化本质上是对资源的合理利用将更珍贵的资源用在更重要的业务上从而实现资源的充分利用资源的合理利用。性能优化的对象包括业务运行的容器、业务依赖的中间件、业务依赖的数据库存储的优化性能优化包括两部分一、发现需要性能优化的点二、改造代码设计实现性能优化 CPU的开销有限的cpu无法支撑更大的业务 性能问题CPU利用不充分有限的CPU无法更好的支撑业务RT问题
一、发现需要性能优化的点
对于业务容器来说需要性能优化的点往往是对系统开销最大的业务方法这部分代码功能上并没有任何问题但在性能上并不是最优在资源比较充足的情况下这部分逻辑并不会导致性能问题但当系统压力比较大或者业务流量比较高的情况下这部分就会成为压力最大的点。
1 放大系统的流量
将流量在部分容器上做放大利用工具采集系统中的堆栈及性能数据。放大系统流量的情况下需要提前关闭应用及容器的限流可以利用Sentinel脚本调整。
### 取消限流 2.Xcurl http://localhost:8719/switchSet?valuefalse
### 取消限流 3.Xcurl http://localhost:8718/setSwitch?valuefalse一、Duct引流验证
Duct引流 duct调整某一台机器的CS权重将其他容器的流量引流到对应的ip上从而实现压力的放大。 二、Amazon构造压测数据验证Amazon压测根据特定的业务场景构造压测压测数据压测模型在gray4环境中打一部分压测流量利用压测流量将系统的负载打高。Amazon更适用于大促场景下的性能优化能确定某些接口的比例及场景的比例。 2) 利用工具采集系统热点
系统负载流量增加后各个环节的系统性能消耗都会被放大此时利用工具可以分析系统的性能情况。系统分析工具会带来系统压力增加非必要情况下尽量在隔离环境统计数据。
Arthas性能数据采集
Arthas提供了非常多的工具脚本其中一部分数据组合起来使用可以很方便的辅助做性能分析及线上问题排查这里对其中常用的指令及使用场景做汇总。安装方式curl -sLk ops.jm.taobao.org:9999/pandora-web… | sh 图 1.1 Arthas指令集合列表性能分析及问题分析工具说明
指令说明性能分析及问题排查的场景classloader查看当前JVM下ClassLoader的列表及加载的实例统计信息- 常见于排查Metaspace空间利用率问题常见的场景是由于Groovy脚本导致的Metaspace增加进而导致应用FGC的问题排查jad反编译- 常见于黑盒分析无法快速活的源码的情况下分析程序内部逻辑的场景getstatic获取静态字段的值- 常见于分析开关、配置、部分数据的情况在分析性能数据时可以辅助排查stack 从当前方法点打印堆栈- 常见于分析热点方法调用来源结合条件过滤可以快速定位到异常数据产生的来源以及调用频率trace从当前方法下钻- 常见于分析耗时情况分析某一个方法耗时的原因。比如分析鹰眼某一个接口耗时很高的原因watch查看方法调用的参数及返回值- 分析线上方法的入参及返回值结合条件判断可以快速知道某一个函数可能走到的场景optionsArthas的一些选项- 在需要分析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对应的文件数据。
[arthas2093]$ profiler startProfiling started[arthas2093]$ profiler stopOKprofiler output file: /home/admin/ump2/bin/arthas-output/20230213-191902.html[arthas2093]$ exit场景二、JVM内存中分配了比较多的对象但很快回收希望找到临时对象创建比较频繁的堆栈。
[arthas2093]$ profiler -e alloc startProfiling started[arthas2093]$ profiler stopOKprofiler output file: /home/admin/ump2/bin/arthas-output/20230213-192148.html[arthas2093]$ exit场景三、应用启动速度比较慢希望找到原因。
[arthas2093]$ profiler start -e wallProfiling started[arthas2093]$ profiler stopOKprofiler output file: /home/admin/ump2/bin/arthas-output/20230213-192812.html[arthas2093]$
场景四、利用JFR分析JVM整体的运行情况采集数据用作分析。
[arthas82348]$ jfr start -n test[arthas82348]$ jfr stop -r 1 -f /tmp/1.jfrStop recording 1, The result will be written to:/tmp/1.jfr图1.2 JFR数据示例
天巡数据采集性能数据
工具地址 explorer.alibaba-inc.com/perf/#/prof…](p3-juejin.byteimg.com/tos-cn-i-k3… 天巡白屏化采集性能数据天巡功能采集指标说明注意 指标采集功能从实现上基本都是在运行的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.tgzyuque.antfin.com/attachments…
sudo yum -y install perfsh create-java-perf-map.sh# 采集性能数据sudo perf record -ag # 分析性能数据sudo perf report图1.4 利用Perf结合perf-map-agent 分析高CPU消耗数据二、利用jstack分析应用的启动情况分析应用在启动过程中应用运行的堆栈进而分析出启动过程中应用执行耗时最多的热点代码进而针对性的做启动优化
$cat 1.shfor i in seq 10000do/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:formatb,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#newHashMapWithExpectedSizecom.google.common.collect.Sets#newHashSetWithExpectedSize | | - 热点的计算压力适当的利用缓存的方式减少系统压力 | - 对于热点数据的计算结合业务合理利用缓存降低计算的压力。 | | - 二分查找、hash、bloomfilter、字典树、hyperloglog、bitmap、hashset | - 合理利用数据结构解决业务问题。结合业务数据降低计算的复杂度。合理的利用其他组件中提供的能力解决业务问题 |
三、影响性能的因素
经常会出现同样是8C16G的容器但表现出来的性能确差异很大这个在集团内表现尤为明显这种情况实际和集团内部的编排策略有一定的关系。也可能和集团内部的机型差异存在关系。一、由于机型原因引起性能差异目前集团存在多种不同的机型F4x、F5x、F6x、M机型等。不同的机型单核性能上表现会有差异。
机型识别方式性能说明F4xcat /proc/cpuinfo查看CPU型号及频率- F6x 8269CY
F5x 8269F4x E2xxxuname -a 查看Cpu架构- x86_64 X86aarch64 倚天机型 | 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 未编排容器此时容器的性能表现最好应用独占整个CPU8C16G容器独占使用跨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量级均非常小若干个业务共用同一套存储不会带来太大的问题对于缓存需要重点考虑的就是隔离的问题这部分可以通过工具方式解决。
行动吧在路上总比一直观望的要好未来的你肯定会感 谢现在拼搏的自己如果想学习提升找不到资料没人答疑解惑时请及时加入扣群 320231853里面有各种软件测试开发资料和技术可以一起交流学习哦。
最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走
这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你
