大发彩神在线官网官方快被系统性能逼疯了?你需要这份性能优化策略

  • 时间:
  • 浏览:88
  • 来源:极速大发快3-1分快3官方

作者介绍

刘迪伟,就职于世界五***银行。负责公司网银业务系统的设计和交付大发彩神在线官网官方,擅长并持续关注Java性能优化、DevOps等领域。

XX银行网银系统是一套全新的对公业务渠道类系统,经过两年的建设,将逐步对外提供服务。

该系统融合了另另另有兩个个对公渠道系统,并发量是本来我多个系统之和,吞吐量要求将大幅上升。为了使广大对公客户使用系统时获得减慢的响应时间体验,项目组对系统进行了持续的性能测试和优化。四种 过程中,形成了一套针对新建系统进行性能测试和优化的法律法律法律依据论。

该法律法律法律依据论包括测试环境准备、测试功能优先级、性能优化原则、常用性能指标及工具、工具使用法律法律法律依据、常见性能什么的现象原困 和优化法律法律法律依据,以及典型案例和进一步优化法律法律法律依据的讨论。

将会系统将会开发完成,根据性能优化修改范围尽将会小且不引入更多什么的现象的原则,本文将只讨论对系统进行局部优化的法律法律法律依据,而系统初始设计时为了提高性能而进行的设计没得讨论范围之内。

我们歌词 歌词 歌词 我们歌词 歌词 歌词 我们歌词 歌词 歌词 我们歌词 歌词 歌词 儿使用Linux操作系统,压测工具为load大发彩神在线官网官方大发彩神在线官网官方Runner,后面 件版本包括IHS8.5.5.9、WAS8.5、IBMJDK1.7(IBM J9VM)、DB2V10、Redis3.2.3。

一、应用系统性能评价指标

  • 响应时间:尽快的给用户返回响应,体现系统防止请求的波特率;

  • 吞吐量TPS:每秒完成的事务数,体现系统防止能力;

  • 并发性:业务请求高并发时,系统还还要稳定运行;

  • 扩展性:单机防止能力过高 时,系统还还要横向扩展。

TPS = 并发用户数 / 响应时间

二、常见性能监控指标及工具

1、操作系统监控指标及工具

主要监控指标:CPU、系统CPU、内存、磁盘IO、网络IO、请求耗时。

常用命令:

  • top –H –p pid:cpu负载监控,实时查看占用cpu高的系统程序运行运行;

  • vmstat:系统负载监控;

  • pidstat:cpu让步式上下文切换监控,监控锁竞争;

  • iostat:磁盘利用率监控;

  • nmon:监控cpu、内存、io使用率 ./nmon -f -t -s 2 -c 1150 每2秒收集一次,共1150次;

  • netstat -anp|grep端口或IP|grep ESTABLISHED|wc -l:服务器连接数监控。

2、JVM监控指标及工具

  • Jconsole,监控cpu、内存垃圾回收。

JVM启动参数中增加:

-Dcom.sun.management.jmxremote.port=1088

-Dcom.sun.management.jmxremote.authenticate=false

-Dcom.sun.management.jmxremote.ssl=false

  • jvisualvm,cpu采样、java法律法律法律依据耗二十四时析、jvm系统程序运行运行栈快照、监控cpu、内存垃圾回收。

CPU抽样:

系统程序运行运行快照:

  • jca457.jar,ibm javacore系统程序运行运行快照分析:

  • ga456.jar,ibmjvm垃圾回收gc分析:

  • ha456.jar,ibmjvm内存,heapdump分析,内存溢出时使用;

  • TProfiler,cpu采样、java法律法律法律依据cpu耗二十四时析,cpu高,响应慢时使用;

  • JProfiler,cpu采样、java法律法律法律依据cpu耗二十四时析,cpu高,响应慢时使用;

  • OracleDeveloperStudio12.6-linux-x86,cpu采样、java法律法律法律依据cpu耗二十四时析,cpu高,响应慢时使用。

三、性能测试前置条件

1、数据库表数据量准确

要大发彩神在线官网官方生和熟产数据量保持一致,大慨另另有兩个数量级。数据分布尽量均匀。

2、测试环境生和熟产一致

测试环境机器配置、参数、代码尽将会生和熟产保持一致(数据库服务器硬件除外)。

3、合理选者并发用户量

系统并发用户量有多种算法还还要估算:

  • 平均并发用户数:

    C=nL/T(n是考察时间内用户登录数,L是用户平均在线时间长度,T是考察值时间长度)

    并发用户数峰值:C’=C + 3*根号C

  • 用户总量/统计时间*影响因子:

    网银用户量1150万,根据2/8原则, 150%用户在上午9点到11点,下午2点到4点之间登录系统,每次登录耗时1到1.5秒。则并发用户为:

    11150000*0.8/4/31500*1.5=82.5,

    11150000*0.8/4/31500*1=55

  • 根据系统用户数计算:

    并发用户数=系统***在线用户数的8%到12%

  • 根据TPS估计:

    C=(Think Time + 1)* TPS,

    网银用户思考时间10s,

    C=(10+1)* 3=33。

4、预估各功能交易量,选者压测功能优先级

根据交易量从大到小排名,排名靠前的优先压测。

5、设置性能什么的现象认定标准

比如响应时间超过3s、TPS低于10、服务器cpu占用率超过70%、jvm堆内存使用1150%、垃圾回收频繁、网络IO或磁盘IO达到瓶颈等……都将会是性能什么的现象。

四、性能优化一般思路

1、找到性能瓶颈

性能瓶颈定义:原困 系统TPS低、响应时间长、资源(CPU、内存、网络)占用高等什么的现象的关键系统程序运行运行模块。提升该系统程序运行运行模块的性能,还还要大幅度改善性能。

常见的性能瓶颈原困 包括:数据库慢查询SQL、日志打印、xml大报文解析和格式转换、繁杂业务逻辑、锁竞争等。

2、咋样找到性能瓶颈

  • 使用LoadRunner给每个接口的增加事务,记录其响应时间和TPS,最慢的那个接口往往是瓶颈;

  • 分析慢交易的日志,查看是哪个操作耗时最长;

  • 分析数据库快照,看是是是不是有执行较慢将会全表扫描的SQL;

  • 通过Javacore查看系统程序运行运行正在执行的代码,是大次要阻塞在IO上,还是大次要在进行计算。针对不同的什么的现象,使用不同的分析工具。删剪内容还还要看下一章节。

3、针对性能瓶颈进行合理优化

性能优化原则:

  • 先优化瓶颈什么的现象;

  • 方案简单,尽量不引入更多繁杂性,尽量不降低业务体验;

  • 满足系统性能要求即可,不引入新的bug。

五、常见什么的现象及优化法律法律法律依据

1、SQL执行时间长

什么的现象什么的现象:系统响应时间长、数据库cpu高。

什么的现象原困 :全表扫描、索引低效、排序溢出。

防止法律法律法律依据:

  • 通过DB2数据库快照查看执行时间长的SQL,查看该SQL执行计划,在cost比较高的SQL上增加大慨索引。要求所有大表SQL执行计划的cost低于1150,超过1150的SQL要评审。对于排序溢出、可参考数据中心规范设置排序堆大小,规范中排序堆设置为AUTOMATIC。

  • 制定数据库表清理策略。根据数据的生命周期要求,对流水类的数据定期进行清理备份,不再长期保留。定期对全库的表型态进行reorg、runstats操作,以提高索引波特率。

排查法律法律法律依据:

  • 获得数据库快照:db2 get snapshot for all on corpdb >gswyzfzzshpl1207.log

  • 从快照中提取慢SQL,Toad查看SQL执行计划

  • Db2命令法律法律法律依据查看SQL执行计划:db2expln -d corpdb -t -g -q "SQL励志的话 "

  • 执行计划查看法律法律法律依据:自上而下查看cost***的分支,找到未走索引或索引使用不当的表

2、数据库出現死锁

什么的现象什么的现象:数据库快照检测到位于数据库死锁,或通过db2evmon -db corpdb -evm DB2DETAILDEADLOCK>dlock.txt生成死锁监控文件,快照或监控文件中位于deadlock的情况汇报。

什么的现象原困 :全表扫描、大事务、更新相同表记录的SQL执行顺序交叉等。

防止法律法律法律依据:缩短事务路径长度,防止全表扫描。将会还要位于大事务,则更新相同表的SQL执行顺序一致,本来我坚决防止全表扫描。网银系统指令发送功能全表扫描+全局大事务,原困 数据库死锁。

排查法律法律法律依据:根据死锁监控文件dlock.txt找到原困 死锁的SQL,以及该SQL持有的锁,分析该SQL将会位于的什么的现象。

3、系统程序运行运行阻塞在日志记录上

什么的现象什么的现象:系统响应时间长、通过javacore查看过多过多系统程序运行运行阻塞在打印日志上。

什么的现象原困 :log4j1.x版本较低,性能较差;大报文日志多次输出。

防止法律法律法律依据:

  • 减少无效日志、删除无用日志,减少大日志输出。

  • 升级log4j组件到log4j2,参考log4j2官方文档,配置合理的日志缓冲区,采用高效的Appenders,比如RollingRandomAccessFile。但log4j2仍然采用同步日志,不采用异步日志。将会网银系统日志量较大,异步日志队列减慢就满了,将会单条日志位于大报文,还有将会原困 内存溢出,本来我不适合采用异步日志。将会日志量少(压测产生日志的波特率,低于日志写入文件的波特率),则还还要使用异步日志,大幅提高性能。将会日志量较大,则不建议使用异步日志。

排查法律法律法律依据:

  • JVM启动参数中增加-XX:+HeapDumpOnCtrlBreak,压测进行时,kill -3 pid 杀几个javacore,使用jca457.jar工具打开并分析。推荐使用该工具,将会该工具还还要对所有系统程序运行运行情况汇报进行统计,并生成饼状图,方便查看。

  • 压测进行时,使用jvisualvm获取jvm快照,分析系统程序运行运行堆栈。

4、多系统程序运行运行并发什么的现象

什么的现象什么的现象:采用合理的并发数压测,系统出現逻辑错误、交易失败或异常报错。经查是将会对象中变量被异常修改原困 。

什么的现象原困 :系统中全局对象中的类变量或全局对象,被多个系统程序运行运行修改。

防止法律法律法律依据:排查系统中所有持有全局对象或类变量的代码,检查其全局变量是是是不是将会被多个系统程序运行运行并行修改。

修改法律法律法律依据:

  • 将全局变量转成法律法律法律依据内的局部变量;

  • 对全局变量进行同步控制比如syncronized代码块,将会java.util.concurrent锁。

排查法律法律法律依据:并发什么的现象很将会是由全局变量将会对象原困 ,准确识别全局变量,通过阅读代码找什么的现象。建议应用梳理所有将会存放全局对象的代码,统一管控,将会把所有全局对象倒入另另有兩个类中,方便管理。

5、打开了过多文件

什么的现象什么的现象:采用合理的并发数压测,交易失败,或后台日志报错:To many open files。

什么的现象原困 :

  • 读取配置文件将会业务数据文件后,未关闭文件流;

  • /etc/security/limits.conf中***打开文件数配置过小。

防止法律法律法律依据:

  • 使用lsof –p pid 命令查看系统程序运行运行打开的文件,将会大次要文件都不 同一类型的文件,说明将会未关闭文件流。找到打开文件的代码,关闭文件流即可。

  • 将会不位于未关闭文件流的什么的现象,且业务四种 就还要防止少许文件,则修改/etc/security/limits.conf文件如下内容:

* hard nproc 10240

* soft nproc 10240

6、内存泄漏

什么的现象什么的现象:JVM内存耗尽,后台日志抛出OutOfMemeryError异常 ;

什么的现象原困 :内存溢出什么的现象将会的原困 比较多,将会是全局的List、Map等对象不断被扩大,也将会是系统程序运行运行不慎将少许数据读到内存里;将会是循环操作原困 ,也将会后台系统程序运行运行定时触发加载数据原困 。

防止法律法律法律依据:对于ibmjdk纯java应用,在jvm启动时设置-XX:+HeapDumpOnOutOfMemory Error参数,会在内存溢出时生成heapdump文件。使用ha456.jar工具打开heapdump文件,分析大对象是咋样产生的。

当然,在heapdump中对象类型将会本来我List四种 型态,看没得具体哪个业务代码创建的对象。此还要分析所有的全局对象,列出可疑的List或Map对象,排查其溢出原困 。

全局对象、引用的初始化、修改要慎重。建议应用梳理所有将会存放全局对象的代码,统一管控。

7、JVM垃圾回收频繁

什么的现象什么的现象:top –H –p pid命令查看,GC Slave系统程序运行运行CPU占用排名始终为前三名,同去Jconsole查看jvm内存占用较高,垃圾回收频繁。使用ga456.jar分析gc日志,查看gc频率、时长。

打印gc日志的法律法律法律依据:在jvm启动参数里增加-verbose:gc -Xverbosegclog:/usr/ebank/ logs/cobp/gcdetail.log

什么的现象原困 :高并发下,内存对象较多,jvm堆内存过高 用 。

防止法律法律法律依据:扩大堆内存大小–Xmx2048m –Xms2048m。

8、CPU高

什么的现象什么的现象:150并发压测,监控工具显示bp、前置CPU占用90%以上。

什么的现象原困 :业务防止中位于少许CPU计算操作。

防止法律法律法律依据:采用更高效的算法、数据型态替换另另有兩个消耗CPU的代码,将会采用新的设计绕过瓶颈代码,比如查找数据的逻辑,还还要把List改为Map,以空间换时间;比如用Json报文替换XML报文,提高传输、解析和打印日志的波特率。

原困 Cpu计算资源高消耗的代码:报文格式转换、加解密、正则表达式、低效的循环、低效的正则表达式。

排查法律法律法律依据:

  • 压测进行时,使用jvisualvm工具远程连接应用,点抽样器àCPU,点快照生成系统程序运行运行快照。采样一段时间后,抽样器会显示各个法律法律法律依据占用cpu时间,还还要针对CPU时间占用高的法律法律法律依据进行优化。

  • 使用tprofiler,jprofiler,OracleDeveloperStudio12.6-linux-x86工具分别分析消耗CPU时间长的法律法律法律依据,以上工具分析结果将会四种 差别。针对CPU计算耗时最长的法律法律法律依据进行优化。

9、批防止时间长、数据库逐笔插入缓慢

什么的现象什么的现象:大批量数据(8万条以上)更新或插入数据库,耗时较长。

什么的现象原困 :批量数据防止时,将会逐条更新数据库,则会位于少许网络io、磁盘io,耗时较长,本来我对数据库资源消耗较大。

防止法律法律法律依据:

  • 采用java提供的batchUpdate法律法律法律依据批量更新数据库,每11150条commit一次,可大幅提高数据更新波特率。

  • 单系统程序运行运行改成系统程序运行运行池,并行防止,充分利用多核CPU,通过数据库将会四种 同步锁控制并行性;增加缓冲池,降低数据库或磁盘IO访问频次。

10、数据库CPU高

什么的现象什么的现象:后台指令发送满负荷工作时,数据库CPU高。

什么的现象原困 :后台指令发送系统程序运行运行每次对全量查询结果排序,结果集很大,本来我取一根记录;索引区分度不高,满负荷执行时;查询频率很高;压测显示,并行发送指令的后台系统程序运行运行过多,数据库CPU越高,波特率越低。

防止法律法律法律依据:

  • 加带ORDER BY,增加索引后,效果不明显。将会结果集大和查询频繁另另有兩个什么的现象这麼防止,本来我考虑使用设计新的方案。

  • 新方案:设计指令发送系统程序运行运行池,生产者系统程序运行运行每台任务服务器只另另有兩个多系统程序运行运行,负责查询待发送指令,每次查询150条指令。每条指令包装成另另有兩个Runnable对象,倒入ThreadPoolExecutor系统程序运行运行池,系统程序运行运行池大小参数设置为1150或150。每当系统程序运行运行池满时,生产者停止生产指令,休息15秒后继续。消费者系统程序运行运行即系统程序运行运行池里的系统程序运行运行,参数设置为4,8或12(和不同指令类型的指令数据量成正比)。

改进后的方案,数据库CPU降到10%一下,发送波特率单机提升6倍,且可线性扩展任务服务器。

11、压测TPS曲线剧烈下降或抖动

什么的现象什么的现象:150并发压测,TPS曲线正常应该是平缓的,波动不大,将会时不时 出現剧烈下降,本来我短时间内无法恢复,则将会位于什么的现象。

什么的现象原困 :一般是将会前置或bp的jvm进行垃圾回收,将会日志记录磁盘满原困 的。

防止法律法律法律依据:将会都不 不得劲剧烈的波动将会TPS曲线下降后长时间不反弹,则还还要忽略该什么的现象。本来我,还要分析曲线下降的时刻,系统当时正在位于的事情。还还要通过top命令监控当时CPU占用比价高的系统程序运行运行,也还还要kill -3 pid杀javacore来查看系统程序运行运行堆栈。

六、优化案例

1、网银系统基本情况汇报

1) 压测环境系统架构

压测环境不包括F5,必须1台WEB、1台前置(应用服务器)、1台BP(业务防止服务器)、1台DB、1台Redis服务器。

2)客户请求链路:

客户端压力机-〉Web-〉PRE-〉BP-〉DB2 ;

客户端压力机-〉Web-〉PRE-〉BP-〉挡板服务器(模拟后端服务方)。

3)系统特点:

  • 用户、账号权限校验较多。

    对公业务典型场景:经办、审核、查询、下载、批量。用户权限通过业务链控制。

  • 接口调用较多,且由前端组合调用接口。

    前后端分离,前端通过调用另另有兩个个接口来完成业务。接口粒度较细。登陆、支付转账经办还要15~19个接口完成一次交易。

  • 强一致性、高可用性。

    资金交易系统,一致性还要通过数据库来保证。

4)网银登录压测曲线

2、数据库消息队列案例(指令发送队列)

需求是:对于还要异步防止的交易指令,还要设计另另有兩个基于数据库的消息队列,我们歌词 歌词 歌词 我们歌词 歌词 歌词 我们歌词 歌词 歌词 我们歌词 歌词 歌词 儿称之为指令发送队列。该队列既要满足服务器的性能约束,又要满足每日防止交易量的要求。

1)优化前防止过程

后台任务每次从数据库指令表中排序并取最早的一根指令,获取该指令的删剪交易信息,组装成报文并调用接口发送后台核心系统。

在压测环境下,该方案将会配置另另有兩个后台任务,无法达到系统设计的指令防止波特率;将会配置多个后台任务,则会原困 数据库CPU占用较高,影响四种 联机业务的开展。

2)优化后防止过程

每台后台任务服务器配置另另有兩个生产者任务,20个消费者任务。

生产者任务一次取1150个(可配置)指令,依次分配给20个消费者任务中空闲的任务,消费者任务获取指令删剪信息,并组装报文后发送后台核心系统;生产者任务将会发现无空闲消费者任务,则等待时间15s后重新判断。

此方案显著降低了数据库CPU负载,合理利用了应用服务器的并发能力,防止波特率大为提高,以上系统程序运行运行数和每次获取的指令数还还要配置。

指令发送系统程序运行运行池模型图:

3、数据库死锁案例

1)死锁什么的现象什么的现象

当多台任务服务器同去运行大额指令发送后台系统程序运行运行,即多个生产者系统程序运行运行并行更新数据库指令表时,数据库快照检测到位于数据库死锁,或通过db2evmon -db corpdb -evm DB2DETAILDEADLOCK>dlock.txt 生成死锁监控文件,快照或监控文件中位于deadlock的情况汇报。

DB2数据库有自动解除死锁功能,死锁超时时间默认为10s,数据库会随机选者另另有兩个死锁事务kill掉。本案例将会是后台任务,过多过多用户感觉必须死锁;将会是联机交易,另另有兩个用户会发现交易失败,另另有兩个用户交易成功,本来我会感觉交易减慢。指令发送后台任务模型详见下一章节内容。

2)数据库死锁位于原理

另另有兩个不同的数据库事务使用排它锁锁住了同一张表的不同行记录,本来我互相等待时间读取对方锁住的行记录。

3)原困 死锁的将会原困

全表扫描、大事务、事务之间对死锁访问顺序交叉等。

4)死锁什么的现象排查过程

Step1:分析数据库快照和死锁监控日志,查看原困 死锁的SQL,定位什么的现象SQL。

Step2:什么的现象SQL不位于事务之间对死锁访问顺序交叉的情况汇报,当时尚不清楚系统程序运行运行中的全表扫描、大事务将会会原困 死锁,本来我做了以下实验:

  • 模拟什么的现象SQL在另另有兩个不同的数据库客户端执行SQL,查看数据是是是不是更新成功。

  • 删剪按照源系统程序运行运行的SQL逻辑执行验证:

UPDATE ( SELECT BP_SRVR_IP FROM ${tableName} WHERE TSK_STAT='TODO' AND ( BP_SRVR_IP IS OR BP_SRVR_IP='') AND PRTY =? AND eff_tm <= CURRENT TIMESTAMP FETCH FIRST 150 ROWS ONLY WITH RS) t SET BP_SRVR_IP=?

  • 不加索引,A事务在R加带了X锁,B事务无法在任何记录加带X锁,B事务会等待时间A事务提交后加带锁。

  • 增加索引,A事务在R记录加了X锁,B事务在S记录加X锁,互不冲突。

Step3:实验发现查询SQL增加with RS隔离级别,查询波特率会更高。当A事务已对记录R加X锁,B事务扫描到R记录时,将会是CS隔离级别,B事务会自动退出,返回空结果集;将会是RS隔离级别,B事务会等待时间A事务完成后,跳过R记录,对符合条件的R+1记录加X锁。

Step4:PRTY字段增加索引,这麼出現死锁什么的现象;将会不加索引,维持全表扫描不变,大事务改成小事务后,也这麼出現死锁什么的现象。

5)两点经验

  • 还要提前熟悉DB2锁的种类和作用,隔离级别的种类和作用,表锁和行锁位于的条件。比如,全表扫描时,DB2会在整个表加带表级锁;将会是增删剪操作,会加表级排他锁。

  • 在不清楚死锁原困 时,将会不了解锁的机制和隔离级别机制时,不同隔离级别下SQL的影响范围,还还要在数据库客户端工具上进行手工小实验,验证数据库机制以及猜想。

七、后续提升网银系统性能备选法律法律法律依据

1、增加缓存的使用

  • 对于读多写少的数据,还还要加载到分布式缓存,降低数据库压力;

  • 目前将会将次要参数和错误码数据倒入分布式缓存,后续谨慎提高缓存使用率,降低数据库压力。

2、精简BP日志。删除交易访问记录日志表的操作。

3、合并、精简接口数量,前端缓存数据。

【编辑推荐】

【责任编辑:

张燕妮

TEL:(010)684761506】



点赞 0