主要通过服务器性能、数据库负载、Top事务三个维度进行分析。其中，服务器性能分析可以对主机的CPU、内存、SWAP、I/O等多个维度指标进行分析判断，确认问题后再通过相关日志（例如系统日志、OSW等）进一步对问题排查；
数据库负载分析可以对数据库当前的等待事件进行归类整理，通过性能图表及Top会话可以很直观的看出当前数据库存在的主要问题，并对引起数据库负载升高的原因进行排查。
Top事务可以对应用程序/数据库中响应时间较长的事务进行分析，并与应用开发同事共同对引起事务响应时间较长的原因进行排查。
根据精细化运维平台提供的SQL信息，如执行时间、物理读、相关对象统计等信息判断SQL对数据库产生的影响，对SQL性能及能否优化做出初步的判断。如果可以优化，那么再根据执行计划、索引等信息对SQL语句采取相应的优化措施。
下面主要通过3个实际工作中的案例，给大家介绍下借助精细化运维平台的优化流程及解决方案，3个案例分别是：
案例1、某系统单据查询优化
案例2、某平台ETLSQL优化
案例3、某系统档案查询优化
单据查询是该系统的核心业务之一，该模块自上线以后随着数据量的不断增大开始出现了性能问题，主要表现在：
1、模块的响应时间较长；
2、在业务高峰时段并发数较高时，系统CPU使用率飙升，进而影响了其他模块的正常运行。
收到用户反馈后，通过精细化平台对应用程序在业务高峰期时占用系统资源较多的事务进行抓取，并对事务中的SQL语句进行定位。
selectt1.* from(select * fromau leftjoin ac onac.ct_number = au.agent_code whereau.repair_no like %XXXX%) t1, (selectform_id, max(task_id), max(audit_node) fromt whereform_type = 01 groupby form_id) t2 wheret1.id = t2.form_id orderby t1.repair_no |
该模块对应的SQL为一条简单查询语句，视图t1和视图t2做关联，从执行计划中可以看到，两个视图做了VIEWMERGE，ac表和au表关联后，再去HASHt表。这里存在的问题是，每次au表模糊查询返回的结果集数量非常少，但优化器仍然将ID=5的Rows估算为1178（num_rows* 5%），进而导致优化器将NL的COST算多，导致T表（该表较大）进行了全表扫描，而不是采用（acjoin au） NLT的连接方式，造成了性能瓶颈。
由于优化器对双边模糊查询Rows估算的特殊性，导致在统计信息准确的前提下对执行计划的选择出现了偏差。在应用侧暂时无法修改代码的前提下，针对该问题我们主要做了如下优化措施：对模糊查询相关表的统计信息删除，使用动态采样。
优化后，通过精细化运维平台可以看到，系统CPU资源得到了较大的缓解，查询模块的响应时间也由长时间卡顿优化至1秒内返回结果，较大程度的提升了用户的体验。
该平台每月月初会有定时调度对上个月的少数异常数据进行删除，每次执行时，系统性能问题较为明显，主要表现在：
1、系统I/O资源占用明显；
2、异常数据的清理模块通常要执行60小时左右，导致每月月初的前两天该系统几乎处于卡顿状态。
下图为该模块执行时，系统的I/O情况：
在语句执行期间，我们通过精细化运维平台TopSQL模块快速定位至相关SQL：
SQL详情页显示，相关会话的活动百分比占用了42%，SQL语句的平均逻辑读、物理读及耗费的DBTime等均占用较大。
deletefrom ci o whereexists (select t.machine_no, t.plat_flag fromci t wheret.machine_no = o.machine_no andt.plat_flag = o.plat_flag andt.month_time = 2019-02 groupby t.machine_no, t.plat_flag havingcount(*) > 1) andexists (select 1 froms_info s wheres.area_no = substr(o.machine_no, 1, 7) ando.cname <> s.cname); |
该模块对应的是一条delete语句，相关SQL语句及执行计划显示出两点问题：
1、分区表没有做分区裁剪，体现在ID=5的PARTITIONRANGEALL操作，该表按月分区，每月数据量为15G左右，目前有80个分区，全分区扫描严重影响了系统资源；
2、对大表的IX_CI1索引扫描次数较多（exits中groupby having写法造成的filter操作，且连接列machine_no基数较大）。
了解用户需求并定位至性能瓶颈后，我们对相关语句进行了改写，由于每月的异常数据量较少，因此我们采用了rowid的方式：
1、利用分析函数将异常数据提前计算，保存异常数据的rowid。
2、使用rowid驱动主表进行快速删除。
delete/*+ use_nl(c) */ fromci c whererowid in (select /*+ full(t) leading(s) use_hash(t) */ t.rowid from(select t.cname, t.machine_no, count(*)over(partition by t.machine_no, t.plat_flag) cnt fromci t wheret.month_time = 2019-02) t, s_infos wheret.cnt> 1 andsubstr(t.machine_no, 1, 7) = s.area_no andt.cname <> s.cname); |
通过等价改写后，整个模块的性能开销仅为对单个分区的扫描操作，性能得到大幅的提升，通过精细化运维平台显示，优化后，系统的性能得到了明显的改善：
1、服务器的I/O资源得到了较大程度的缓解，iowait降至5%以内；
2、数据库的整体负载降低约60%，物理I/O降低约80%；
3、解决了模块执行时间过长的问题，经过优化该模块的执行时间降至20分钟左右完成，优化效果较为明显。
该模块上线后，点击查询（由于总体返回的数据量不多，因此没有设置过滤条件）按钮长时间无响应，系统CPU资源飙升，占用明显。通过精细化运维平台显示，在模块执行期间，系统CPU使用率在90%左右。
通过TopSQL模块定位至相关语句，通过SQL详情页显示，该SQL语句占用了近75%的系统资源，总逻辑读达到3亿，执行时间已超过50小时，消耗了大量的DBTime，严重影响了数据库性能。
selectws.id, wa.ct_number, ms.business fromws leftjoin wa onwa.ct_number = ws.ct_number leftjoin ms onms.station_code = ws.st_number wherews.status = 有效 and(select count(1) fromwb leftjoin wr onwr.wp_no = wb.wp_no wherewr.is_urgent = 1 andwr.service_no = ws.st_number) < ws.pg_number; |
该模块对应的是一条查询语句，结构相对比较简单，关联后通过标量计算对结果集进行过滤，通过相关执行计划可以看到，标量部分的WB与WR表关联了多次，造成了性能瓶颈。
确定了SQL语句存在的性能问题后，我们对相关SQL语句进行了改写，通常的优化方案是对标量部分进行改写，然后通过控制执行计划改变标量的连接方式，提升性能：
selectws.id, wa.ct_number, ms.business fromws leftjoin wa onwa.ct_number = ws.ct_number leftjoin ms onms.station_code = ws.st_number leftjoin (selectwr.service_no, count(1) cnt fromwb leftjoin wr onwr.wp_no = wb.wp_no wherewr.is_urgent = 1 groupby wr.service_no)cc on(cc.service_no = ws.st_number) wherews.status = 有效 andnvl(cc.cnt,0)< ws.pg_number; |
通过等价改写后，整体的系统性能得到大幅提升，从精细化运维平台对比优化前后的系统负载：
1、系统CPU由90%的使用率降至10%以内，大幅降低了系统的整体负载；
2、系统逻辑读由平均4K/s降至1.8k/s，有效的降低了I/O带来的性能开销；
3、相关模块性能提升较为明显，由长时间无响应缩降至1秒左右完成；
本篇文章主要给大家介绍了借助精细化运维平台辅助优化的总体流程，当遇到性能方面的问题时，我们可以借助现场已有平台工具的各个分析模块来快速的发现问题、分析定位并针对性的优化，提高工作效率的同时也较大程度的缩短了利用传统方式处理问题的时间，做到精细化运维。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/130203.html
摘要：开启验证上传一张新图片，使用手安卓版本访问已支持域名的图片，如果请求带了，检查返回图片格式是否为如果旧的图片未按预期返回，返回了或原图可能是结点缓存，正常天后过期回源则会返回图片。 对于图片较多的网站，本文结合具体案例给出了如何基于CDN的sharpP自适应图片无痛接入方案，据统计效果可在原图基础上节省60%-75%的流量。作者：陈忱 出处：腾云阁文章 目前移动端运营素材大部分依赖图...
摘要：基于云迁移的三个阶段细分为八个主要步骤，评估阶段主要包括项目启动现状梳理以及应用系统关联关系分析三个步骤，设计阶段包括云架构优化设计和云迁移方案设计，实施阶段包括目标架构迁移演练及实施和试运行三个步骤。 在云计算市场规模不断扩大的大背景下，云迁移的需求越来越大且面临挑战。云迁移不是一个迁移软件工具，而是一种服务。前IBM资深架构师姜亚杰从云迁移的三个阶段、四个维度到八个步骤的方法，简述...
摘要：主要介绍了美团智能支付业务在稳定性方向遇到的挑战，并重点介绍在稳定性测试中的一些方法与实践。其中，智能支付作为新扩展的业务场景，去年也成为了美团增速最快的业务之一。 本文根据美团高级测试开发工程师勋伟在美团第43期技术沙龙美团金融千万级交易系统质量保障之路的演讲整理而成。主要介绍了美团智能支付业务在稳定性方向遇到的挑战，并重点介绍QA在稳定性测试中的一些方法与实践。 背景 美团支付承载...
摘要：无代码时代来临业务问题，而不只是机器学习我们希望企业可以用的时间来解决业务问题，而不是机器学习问题，谈到整个人工智能和数据行业的未来发展时，黄一文这样说道。 showImg(https://segmentfault.com/img/remote/1460000018912276); 玛丽·雪莱在创作世界上第一部科幻小说《科学怪人》（又译：弗兰肯斯坦）的时候，恐怕没法预见到在一个多世纪后...
阅读 1348·2023-01-11 13:20
阅读 1690·2023-01-11 13:20
阅读 1141·2023-01-11 13:20
阅读 1865·2023-01-11 13:20
阅读 4104·2023-01-11 13:20
阅读 2714·2023-01-11 13:20
阅读 1390·2023-01-11 13:20
阅读 3602·2023-01-11 13:20
