性能调优事例

 

1 脚本是优化的     
 1.1对于BS结构的脚本录制 尽可能将一些图片请求 或者重复请求 或者是 动态刷新页面的请求所有干掉      
 1.2 函数使用 ：正式跑场景的时候将调试函数屏蔽 lr_out_message   lr_log_message   lr_error_message 等  关联函数的参数选择 ---- to_date to_char    
2.客户端：压力机自己优化  其目的是别让压力机端口存在堵塞现象    
3.网络  看网络存不存在丢包    
4.应用服务器：sysconf   sysctl -a  > sysctl.txt   、与数据库链接配置文件     
  应用日志步骤： 看耗时状况    
5.中间件 :tuxedo （域服务器配置） weblogic  JDK   MQ  Congnos  nginx   F5 等      
      
6.数据库 ：Oracle   DB2    infomix 等    
    
7.架构:    
    
--------------------------    
参数化策略：每次迭代、每次出现、只取一次    
        顺序、随机、惟一
    
#AIX系统：    
#1.判断内存不足：svmon -G:   virtual值大于size,则代表物理内存不足，换页不可避免，只能在硬件上升级物理内存或者配置用户应用，经过减少应用对内存的需求量来解决。    
                 vmstat:收集内存使用数据和换页数据；fre，avm:表示系统工做所需的页面数；avm > fre,代表换页。    
                 lsps:收集换页空间的使用状况。    
    
    
---------------------内存泄漏产生的缘由-----------------------    
一、分配万内存后忘记了回收    
二、程序代码有问题，形成没有办法回收    
三、某些API函数操做不正确，形成内存泄漏    
    
---------------------------注意：-----------------------------    
若是重启机器后，cache没有被释放，可进入/proc/sys/vm中使用echo 2 >drop_caches命令释放cache。    
    
--------------------------------------------------------------    
HTTP录制协议关联：    
insert--->搜索web_reg_save_param进行关联，关联函数要放在参数字段语句上面，打印日志函数要放在参数字段语句的下面。    
登录的关联最好是登录的帐号或密码    
    
--------------------------------------------------------------    
xml格式转换：    
一、视图中的选择XML格式    
二、格式中选择XML转换格式    
    
编写测试报告时问题分析：    
一、对问题分析要深刻，排除自身的影响    
二、要注意格式的排版    
    
--------------------------------------------------------------    
统计当前目录下（包括子目录）全部文件个数    
ls -lR |grep "^d" |wc -l    
    
--------------------------------------------------------------    
java 程序的项目都须要监控VmRss、Vmsize    
VmRss:虚拟内存驻留集合大小。这是驻留在物理内存的一部分，它没有交换到硬盘。它包括代码、数据和栈。    
Vmsize:虚拟内存大小。整个进程使用虚拟内存大小，是VmLib、VmExe、Vmdata、Vmstk的总和。    
    
---------------------------------------------------------------    
Tuxedo脚本调试：    
一、了解服务器端Tuxedo版本，本地控制机安装Tuxedo客户端，配置环境变量    
二、了解WSL访问方式（IP:Port）    
三、了解研发使用的Tuxedo服务名、数据缓冲类型（如：CARRAY、FML32等）、缓冲区长度（如1024*1024*3）    
四、了解这个缓冲区类型的缓冲结构（包括哪些字段，这些字段的属性（数据类型、数据长度等），以及这些字段要放置什么数据，是任意数据仍是指定的死数据）    
五、了解报文（报文长度、内容、详细信息；哪些数据须要作参数化；调研报文的格式，是否经过在脚本中组装报文，是否能够经过从报文文件中获取报文）    
六、了解报文发送后服务器返回的数据内容、长度等，用做在脚本中判断事物是否成功    
    
---------------------------------------------------------------    
三层架构:    
客户端（表现层） 中间件服务层（业务逻辑层）  数据库服务器层（数据层）    
应用weblogic中间件的系统通常采用的B/S架构，绝大部分采用HTTP协议，少许的系统用JAVA编写的客户端，使用的是RMI协议，或J2EE里的协议。    
    
-----------------------------------------------------------------    
配置host的路径： C:\windows\system32\drivers\etc    
    
----------------------------------------------------------------    
正则表达式：    
代码   说明    
.      匹配除换行符之外的任意字符    
\W     匹配字母或数字或下划线或汉字    
\S     匹配任意的空白符    
\d     匹配数字    
\b     匹配单词的开始或结束    
^      匹配字符串的开始    
$      匹配字符串的结束    
    
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------    
---------------------------------------------------------------项目调优事项------------------- -------------------------------------------------------------------------------    
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------    
    
1、ECIF    
    
一、问题描述：性能测试组在生产环境对ECIF系统进行性能测试，截止目前发现的问题主要是10并发过程当中发现ESB应用服务器CPU资源消耗太高，在70%左右，而且当中sys%占比较高占资源消耗的50%。    
   问题分析：经分析一个是CPU资源不足，还有一个缘由是应用日志输出过多引发的。    
   问题解决：应用服务器CPU增长至8C，减小了日志中冗余内容的输出。    
    
二、问题描述：ECIF高并发时出现交易大量报错现象。    
   问题分析：交易发送处理完，断开链接，可是未收到客户端的端口关闭动做，致使大量端口被占用，端口资源被耗尽。    
   问题解决：优化了tcp链接参数，调整了系统控制文件（sysctl.conf）里的端口复用和快速回收参数，增长配置参数详细以下:net.ipv4.tcp_syncookies = 1    
                                                                                                                  net.ipv4.tcp_tw_reuse = 1    
                                                                                                                  net.ipv4.tcp_tw_recycle = 1    
                                                                                                                  net.ipv4.tcp_fin_timeout = 30    
    
三、问题描述：性能测试组在生产环境对ESB系统进行性能测试，10并发过程当中发现ESB应用服务器CPU资源消耗太高，在80%左右。    
   问题分析：经技术人员分析缘由是应用日志输出内容过多，致使cpu资源被大量消耗引发的。    
   问题解决：1．优化异步写数据库日志线程池,将JMS队列线程数由20调至50个线程,同时修改了代码处理逻辑。    
             2．优化内部服务控制处理流程。    
             3．关闭非必要输出日志。    
    
2、财务    
    
一、问题描述：发票认证结果交易容量测试过程当中，随着并发数的梯度增长，应用服务器CPU资源消耗和交易TPS无明显增加，交易响应时间明显变长。    
   问题分析：经与技术人员调试分析，该交易因为业务须要，凭证号码必须是按照顺序生成，凭证号生成过程当中采用单线程方式，所以致使该问题和现象。    
   问题解决：  技术人员分析，要实现顺序生成凭证号的业务规则只能采用单线程方式，而且发票认证业务属于审批类交易，在生产上属于权限较高的业务，并不存在高并发高压力的问题，目前测试的结果，从响应时间和TPS以及资源消耗状况来看，都能知足从此生产须要，故经项目组赞成该问题暂不处理。    
    
二、问题描述：在对F5可靠性测试过程当中，当停掉一台应用服务和重启服务后，TPS未能恢复到最初水平，交易一直报错，错误提示：发票代码：XXXXXX,发票号码XXXXXX，数据已经被锁定，请等待；而且出现终止测试场景，曾被停掉服务的应用服务器cpu资源仍然占用100%现象。    
   问题分析：经与技术人员分析，交易在执行过程当中，程序须要对该数据进行加锁处理，当交易完成后再释放锁，但未考虑执行交易过程当中出现交易中断，释放锁的处理逻辑，所以形成死锁现象发生。    
   问题解决：取消了程序中加锁的代码。    
    
3、新柜面、无纸化    
    
一、问题描述：执行稳定性测试，在info级别下会记录大量的日志，没法支撑24小时，另外应用服务器的SWAP分区因内存不足被逐渐消耗。    
   问题分析：硬件资源内存不足致使。    
   问题解决：将日志级别修改成error级别，服务器的SWAP分区不在被占用。     
    
二、问题描述：执行单交易测试，场景在10用户并发下执行2小时30分钟，随着交易时间愈来愈长，TPS从最高91笔/s降到最低61笔/s，呈现明显降低的趋势；响应时间从最低0.108s上升到最高0.16s,呈现明显上升的趋势；发现数据库CPU资源使用率也愈来愈高，呈现明显上升趋势，CPU资源使用率从最低65.8%上升到最高91.5%；数据库磁盘I/O基本维持在30%左右，呈现逐步降低的趋势。    
   问题分析：经过awr报告分析其中一条sql：select ELECDOCDATE, ELECDOCNO from ab_elec_doclog where CHANELDATE = :1 and CHANELCODE = :2 and VOUTYPE = :3 and PRINTNO = :4 and STATUS = '1'占用65%以上的cpu时间，而且该sql执行了全表扫描。    
   问题解决：项目组优化了ab_elec_doclog表的索引字段，并将索引使用的表空间从系统表空间移到用户表空间。    
    
三、问题描述：执行单交易测试过程当中，发如今10用户并发下，TPS150，数据库I/O仅7M/秒，但数据库服务器磁盘利用率高达50%以上，当加压到20并发时，磁盘利用率就超过80%。    
   问题分析：经过awr报告分析目前每成功一笔交易数据库须要commit 4次，当前10个并发tps为150，就意味着数据库一秒钟commit次数达到150*4=600次，所以致使磁盘利用率和cpu太高的现象出现。    
   问题解决：项目组调整了数据库Commit次数，由原来的4次调整为3次，数据库的磁盘繁忙率在必定程度上获得了缓解，可是当TPS超过300仍然会出现该状况。    
    
4、黑名单    
    
一、问题描述：执行负载测试，当并发用户数从50增长到100时，TPS未相应增长仍然保持在300左右，应用服务器和数据库服务器的cpu使用率也无明显变化，仅交易响应时间从0.15秒增加到0.3秒左右。    
   问题分析：经屡次测试调试，发现日志对交易响应时间和TPS影响较大，当日志级别为error时，50并发tps可达2000；日志级别为info时，50并发tps仅300。    
   问题解决：优化应用程序中日志处理逻辑，去除了冗余日志的输出并把没必要要的日志输出调成了debug，必要的日志调成info级别。    
    
5、统一回单    
    
一、问题描述：单交易基准测试从场景发现回单打印交易在1vu下执行100次迭代，平均响应时间达到4.5秒、回单预览交易平均响应时间达到2.7秒，超过性能指标2秒，且数据库CPU大于20%。    
   问题分析及解决：有执行效率太低的sql致使数据库CPU偏高，响应时间较长。优化sql，增长索引，问题得以解决。附优化后sql：    
    
二、问题描述：单交易负载测试20vu并发，数据库CPUwait%较高，磁盘占用率超过80%。    
   问题分析及解决：代码中有记录日志的操做，并发压力时数据库频繁写日志，致使磁盘IO太高。关闭数据库日志操做，问题得以解决。    
    
三、问题描述：单交易负载测试20vu并发，数据库CPUsys%较高，致使CPU利用率达到100%。    
   问题分析及解决：未找到缘由。更换数据库后，问题获得解决    
    
四、问题描述：容量测试增长并发数后，系统交易平均响应时间逐渐上升，系统处理能力逐渐降低，应用及数据库各项资源指标无明显变化。    
   问题分析及解决：1.压力上不去：接收报文时将报文map转换成object这一步骤时，方法性能不高，压力卡在这一步。后改动mapToObject方法，提升该方法性能，压力提升。    
                   2.第二次压测时，发现明细帐打印响应时间很长，发现是每次明细帐打印时都编译模板，形成性能过低。修改打印方法，只编译一次，之后打印都不编译。性能提升，响应速度下降。    
    
五、问题描述：签约交易单交易并发测试过程当中，数据库磁盘利用率较高超过80%。    
   问题分析及解决：签约交易每发生一笔就会对数据库进行两次insert操做和四次select操做，且每执行一次后都要完成一次commit操做，以上均为正常的业务逻辑操做，没法进一步优化；对压力测试场景增长1ms pacing后，20vu并发复测，数据库磁盘利用率降低到48.9%，平均响应时间为19ms，TPS为628.032笔/秒。    
    
6、外部数据管理平台    
    
一、问题描述： 20个并发执行我的客户信用报告查询申请、我的客户信用报告查询详细信息混合场景10分钟，报“接口运行时异常”错误，且响应时间比较长。    
   问题分析：性能测试环境未铺好，本次是对开发环境进行试压，版本稳定后打包至测试环境。项目组查看后台并通过分析发现，最大线程数是20 ，致使线程池堵塞；计费模块中费用统计同步，配额机制主要统计接口使用次数存在Update操做，致使响应时间比较高。    
   问题解决：项目组调整了以下内容：    
            1.最大线程数由20调为1000；    
            2.计费模块中费用统计由同步调为异步；    
            3.配额机制主要统计接口使用的次数取消了Upadate操做。    
    
二、问题描述：执行我的客户信息报告查询详细信息交易20并发单交易联调测试，报“接口运行时异常”。     
   问题分析：项目组查看后台发现费用流水表被删。    
   问题解决：项目组重建了费用流水表 。    
    
    
7、网联系统    
    
一、问题描述： 执行身份认证及签约交易40并发、60并发单交易试测，响应时间由0.4秒增加至0.55秒，TPS保持在70左右，应用服务器CPU使用率在45%左右，没有明显增长，最大TPS只能达到250左右TPS，资源使用率在60%左右。    
   问题分析：一、项目组分析日志查看日志打印时间间隔，发现日志打印的时间慢。    
             二、根据日志打印定位代码，查看代码块，对代码块进行分析，而后优化接收线程池。    
             三、根据日志状况进行打印日志输出，而后再进行压力测试，发现不打印日志tps可以达到正常值。    
             四、根据不打印日志状况优化日志输出方式，采用log4j输出日志。    
             五、再进压力测试发现单机tps可以达到350。而后再进行log4j版本升级。升级到log4j 2.0版本。     
             六、再进行压力测试，发现单机tps可以达到400以上。    
    
   问题解决：一、优化接收线程池；    
             二、采用log4j 2.0版本输出日志。    
    
二、问题描述： 进行容量测试压测，发现160并发，tps达到400左右，数据库磁盘IO达到70%左右，继续增长并发至180，tps仍是维持在500左右,数据库磁盘IO达到80%左右。     
   问题分析：项目组查看后台发现是数据库的配置不足致使的，如今的配置是4C4G,生产上是8C16G，故配置提高至8C8G；数据库版本如今是11g，生产上版本是12C，故版本升级至12C,相关内核参数作了调整，问题获得解决。    
   问题解决：数据库配置由4C4G提高至8C8G，版本由11g升级至12C，数据库内核参数也作了调整，具体oracle 11g内核参数见附件一，oracle 12C 内核参数见附件二。    
    
三、问题描述：进行120并发400TPS的稳定性试压，执行到6小时左右时，数据库CPU达到100%，磁盘IO也达到100%，且数据库内存存在泄漏问题，执行至12小时时，报大量“系统异常错误”，后台报“【信息：表：【EPCC_MSGRGSTR】,数据入库失败,执行存储过程：PRO_EPCC_MSGRGSTR_01执行失败java.sql.SQLException: ORA-01653: 表 EPCC.EPCC_MSGRGSTR 没法经过 8192 (在表空间 EPCC 中) 扩展】”错误。    
   问题分析：一、项目组查看后台发现系统表空间不足，现有是100g磁盘，没有创建表空间，项目组从新创建表空间，磁盘空间扩至300G。    
             二、打印AWR报告发现SQL“select trxctgy from epcc_msgrgstr where rpflg=:1 and INSTGID=:2 and trxid=:3 ” 耗时比较长，项目组通过分析，发现索引“EPCC        ID1_EPCC_MSGRGSTR  Normal  RPFLG, INSTGID, TRXID  N  Y  N  N        tablespace epcc pctfree 10 initrans 2 maxtrans 255 storage ( initial 64k next 1m minextents 1 maxextents unlimited )” 在数据导入数据库时未及时生效。    
   问题解决：一、项目组从新创建表空间，表空间由32G扩充至160G；    
             二、从新创建了索引“EPCC   ID1_EPCC_MSGRGSTR     Normal      RPFLG, INSTGID, TRXID    N     Y     N     N      N     tablespace epcc pctfree 10 initrans 2 maxtrans 255 storage ( initial 64k next 1m minextents 1 maxextents unlimited )”。    
    
    
-------形成数据库繁忙的缘由------    
一、对数据库的使用过于低效：错误的查询设计、糟糕的应用程序逻辑、对于数据访问框架的配置不正确    
二、糟糕的数据库设计与数据结构：表的关联、缓慢的存储视图、缺失的或错误的索引、过时的表统计信息    
三、不恰当的数据库配置，例如：内存、磁盘、表空间、链接池等