ApplicationPerformanceAnalysisSkillsBasedOnYYY基于友云音的应用性能分析技巧演讲人周娟时间2021-03目录CONTENTS单点效率问题分析1234整体性能提升突发问题诊断查找异常原因-PART01-单点效率问题分析常用场景制单慢场景1：业务操作分析–整体性能剖析场景2：操作轨迹–事务线程分析场景3：事务分析–事务线程对比场景4：智能运维场景5：用户分析–关键用户总结：常见制单，保存-计算慢原因整理场景1-整体分析操作步骤：业务分析-找到具体业务操作-查看性能分析，确认耗时基本原因（代码、网络、数据库）业务“制单-保存”耗时17秒，耗时分析1.Top1事务SQL耗时主要占比2.Top2的SQL是卡慢根因3.单点优化对比优化前优化后场景2-操作轨迹分析步骤：找到关键业务-操作轨迹–查看详情，确认耗时基本原因（网络？服务端？）关键业务“制单-保存”耗时23.9秒1.方法一方法二查看详情，主要原因服务端耗时23.1s2.场景2-事务线程采样SQL获取了20w+的结果集，是对表bd_cashflowuse（现金流量项目使用权）事务耗时19.1秒，查看详情，事务线程分析3.场景3-对比分析现象1：同一个业务员在1月操作耗时于2月操作耗时对比现象2：主要耗时在代码nc.impl.gl.cf.ImpCashFlowCase.querySubByBookAndDate1月操作2月操作场景4-智能运维现象1：制单保存操作长期稳定在1.2s左右现象2：突然有增至2.6s，什么原因导致？场景5-关键用户现象1：关键用户反馈慢现象2：整体业务业务操作平均响应时间正常场景5-关键用户操作步骤：用户分析-找到该用户-找到对应操作，确认耗时基本原因通常可以通过对比定位原因用户甲用户乙制单常见性能原因•项目档案•核销校验数据库(SQL执行效率问题)1.制单常见性能原因•模板中配置的科目校验中含有已停用•单server，锁竞争•日志级别，导致IO等待•现金流量校验代码执行效率问题2.报表计算常见性能原因1.SPR中报”找不到科目”，结果集非常大2.保存计算卡死，从数据库端产生堵塞。同一个人多次重复执行同一个任务效率问题1.-PART02-整体性能提升分析思路业务分析：业务中找到占比资源最多的业务操作，可以根据总耗时排序获取。SQL分析：找到占比资源最多的SQL语句，可以根据总耗时排序获取。事务分析：查找后台任务相关事务发现服务线程（预警、iufo）或第三方接口webservice缓慢问题。Java服务监控：事务监控发现缓慢的时候在jvm里面也可以同步看看响应时间，如果某个server的响应时间达到1秒，基本上系统进入不可用状态。整体性能优化案例1现象2：系统平均响应时间较高现象1：客户反馈MA操作很慢友云音操作性能指标租户操作平均响应时间较快1秒内正常1-2秒较慢2-4秒慢4秒以上业务操作分析-平均响应时间规律总结业务操作分析，平均响应时间3.85秒1.整体性能优化案例1现象1：Top10的慢SQL列表，单次平均耗时都比较高，满意度低现象2：慢事务中也有较多是因为SQL慢导致方案：数据库环境优化，对lsass进程优化，该进程CPU占用过高事务分析&SQL分析，SQL效率是瓶颈2.默认排序方式推荐排序方式整体性能优化案例1数据库环境优化，对lsass进程优化，内存占用3.整体性能优化案例1问题1：单点SQL效率问题问题2：代码效率问题登录、付款单管理类操作查看审批意见一类操作，获取结果集过大问题3：数据库参数设置直接路径读关闭，减少IO消耗(Oracle11g）altersystemsetevent='10949tracenamecontextforever,level1'scope=spfile;平均3.85秒平均2秒优化前优化后单点优化，慢SQL&慢事务4.整体性能优化案例2月结期间，系统平均响应时间5.49秒1.业务操作分析，操作次数&总耗时排序2.操作次数总耗时整体性能优化案例2慢业务操作-性能剖析2.121个用户执行了302次，平均响应时间23.84s，数据库端耗时23.63s17个用户共执行了404，平均响应时间91.51s，代码和数据库占一半，数据库耗时50.87s11个用户执行了710次，平均响应时间25.82s，数据耗时25.68s整体性能优化案例2分析“支付指令状态-刷新”-性能剖析2.2整体性能优化案例2慢业务操作-穿透到SQL分析2.3优化后平均耗时0.4秒，效率提升98%2.4整体性能优化案例2事务分析-慢事务分析3.nc.bs.uap.scheduler.impl.TaskExecutor.executeTask预警任务对账单下载、对账单回写nc.itf.cmp.ebank.ICMPPaymentService.dealOneToOnenc.itf.cmp.settlement.ISettlementQueryService.querySettlementByCondtionnc.itf.cmp.ebank.ICMPPaymentService.dobeforeFillEBank结算-网上转账整体性能优化案例2操作“结算-网上转账”-穿透到事务分析3.1整体性能优化案例2详细事务分析3.2优化后平均耗时6.3秒，效率提升88%3.3整体性能优化案例2SQL分析-慢SQL语句分析4.优化对象：整体性能优化案例2慢SQL分析4.1优化后平均耗时0.4秒，效率提升88%4.2整体性能优化案例3项目性能背景&解决方案1.登录慢，消息表巨大经常大面积系统卡住临时表过多主机内存资源占用网络应用效率低下应用服务器端口响应延迟登录、制单-保存单点效率低下应用服务器迁移WAS集群优化JVM优化数据库服务器优化单点优化网络问题整体性能优化案例3系统大面积卡顿原因2.数据库Oracle数据库运维表空间设置自动拓展，导致表空间满的时候系统响应很慢，插入操作大量卡住，系统无法响应。已经调整成不自动拓展应用服务器应用服务器端口延迟高，代码逻辑刷大缓存对象，导致客户端卡住操作大数据量、开的页签过多，客户端内存溢出网络VPN断开请求被卡在网络层，网络丢包率高，偶尔卡住并且访问慢系统大量生成报表发送消息，大量自定报表，自定义报表产生大量临时表，运维没有及时发现并清理消息导致系统卡慢.整体性能优化案例3应用服务器监控3.现象1：在11月19日开始，突然占用操作系统内存上升到20g左右，导致操作系统内存几乎耗尽，占比96%现象2：分析JVM使用情况，例如取结果集，代码执行等，所有分到此server的任务都会变得很慢整体性能优化案例3JVM服务监控4.在友云音中观察这两个线程堆内存一直保持4G左右，且GC的占用时间高达250s整体性能优化案例3JVM服务监控4.方案1：关闭AIO，未关闭AIO，可能导致内存过度占用方案2：操作系统调整，AIX->X86整体性能优化案例3应用服务器迁移5.由于原生产应用服务器端口响应异常延迟，服务器进行迁移，应用平均响应时间大幅降低，业务数得到明显提升问题1：系统大范围卡住无法进行操作系统问题3：制单-保存操作平均响应时间飙升至64.1s问题2：平均响应时间飙升到9.3s数据库优化6.整体性能优化案例3HW锁争用是在急速空间扩张时普遍出现的等待现象，有时也会引发严重的性能下降问题1：selectfile#,block#fromseg$wheretype#=3andts#=:1问题2：deletefromRecycleBin$wherebo=:1问题3：selectobj#,type#,flags,related,bo,purgeobj,con#fromRecycleBin$wherets#=:1andto_number(bitand(flags,16))=16orderbydropscn解决方案：关闭自动表空间拓展，清理回收站中对象整体性能优化案例3整体性能优化案例3网络应用效率7.问题：以2月19日以操作次数占比超过2%的地区网络情况耗时对比分析，按平均网络耗时<700ms标准，80%以上区域达不到要求方案：应用服务器调整，VPN故障处理等调整后，大幅降低了网络延迟优化前优化后整体性能优化案例3优化对比5.日常月结月结效率提升平日效率提升-PART03-突发问题诊断突发问题速诊断•实时采样•智能运维•报警管理•地域分析突发问题诊断思路突发问题分析思路•整体突然变慢业务平均响应时间大幅度提升，主要从内存、数据库、网络方面进行分析•部分地区突发性变慢地域分析中分析于其他地区的差异情况突发性能案例1-现象现象1：平均响应时间较昨天同一时刻上升现象2：实时采样中有线程运行42h平均响应时间升高、业务操作数下降现象3：数据库CPU利用率超过80%突发性能案例1-实时采样突发性能案例1–分析避免查询条件来源于语义模型！！突发性能案例2-智能告警现象1：智能告警提示发生业务操作性能异常现象2：业务平均响应时间86s现象3：所有的业务操作基本卡住，制单保存都需要23s突发性能案例2-分析突发性能案例2-处理建议关注备份效率，备份操作长时间执行不完有可能会导致业务系统瘫痪常见原因：1.SM_BUSILOG_DEFAULT表较大（可清理）2.SYS_EXPORT_SCHEMA_%表较多（可清理）3.临时表过多（需确认）4.研发或者客开人员做的业务备份表（需确认）5.Oracle的BUG（ID17365043.8）ALTERSYSTEMSETstreams_pool_size=200mSCOPE=both;优化前优化后-PART04-查找异常原因其他异常分析思路网络异常系统运行缓慢，但是本地使用不慢，客户也无法确认是网络问题。在这种情况上可以从地域分析上进行分析判断，看看网络耗时是否存在异常数据库归档增长过快到底是那些业务导致找到表后是否需要逐个模块尽快开发确认？可以通过sql反查业务进行确认那个模块导致的。Sever异常通过友云音可用性告警功能，可以掌握可用性状态。JVM堆内存使用情况掌握运行状态其他异常找证据1归档日志暴增：1.数据库awr进行分析归档增加原因，如果不行还可以做日志分析。2.找到相关表对照友云音里面查找了一下发型确实很多类似的sql，并反向查找了一下业务。发现与固定资产客开的新功能有关，问题快速定位解决。其他异常找证据2Master端口被修改：1.收到友云音告警提示master不可用，但是系统依然显示可正常2.没隔多久内存溢出，业务整个不可用申请试用咨询专家，申请免费试用曹建侬18611269117cjn@yonyou.com.cn蔡平昕13911881254cpx@yonyou.com.cn产品演示网址：yyy.yonyoucloud.com服务官方微信
