刘迪伟就职于世界五百强银行。负责公司网银业务系统的设计和交付擅长并持续关注Java性能优化、DevOps等领域。

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

该系统融合了原来多个对公渠道系统，并发量是以前多个系统之和吞吐量要求将大幅上升。为了使广大對公客户使用系统时获得更快的响应时间体验项目组对系统进行了持续的性能测试和优化。这一过程中形成了一套针对新建系统进行性能测试和优化的方法论。

该方法论包括测试环境准备、测试功能优先级、性能优化原则、常用性能指标及工具、工具使用方法、常见性能问题原因和优化方法以及典型案例和进一步优化方法的讨论。

由于系统已经开发完成根据性能优化修改范围尽可能小且不引入更多問题的原则，本文将只讨论对系统进行局部优化的方法而系统初始设计时为了提高性能而进行的设计不在讨论范围之内。

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

• 响应时间：尽快的给用户返回响应体现系统处理请求的速度；

• 吞吐量TPS：每秒完成的事务数，体现系统处理能力；

• 并发性：業务请求高并发时系统能否稳定运行；

• 扩展性：单机处理能力不足时，系统能否横向扩展

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

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

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

• top –H –p pid：cpu负载监控实时查看占用cpu高的线程；

• vmstat：系统负载监控；

• pidstat：cpu让步式上下文切换监控，监控锁竞争；

• iostat：磁盘利用率监控；

2、JVM监控指标及工具

JVM启动参数中增加：

• jvisualvmcpu采样、java方法耗时分析、jvm线程栈快照、监控cpu、内存垃圾回收。

1、数据库表数据量准确

要和生产数据量保持一致至少一个数量级。数据分布尽量均匀

2、测试环境和生产一致

测试环境机器配置、参数、代码尽可能和生产保持一致（数据库服务器硬件除外）。

3、合理确定并发用户量

系统并发用户量有多种算法可以估算：

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

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

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

  网银用戶量100万根据2/8原则， 80%用户在上午9点到11点下午2点到4点之间登录系统，每次登录耗时1到1.5秒则并发用户为：

• 并发用户数=系统最大在线用户数嘚8%到12%

• 网银用户思考时间10s，

4、预估各功能交易量确定压测功能优先级

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

5、设置性能问题认萣标准

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

性能瓶颈定义：导致系统TPS低、响应时间长、资源（CPU、内存、网络）占用高等问题的关键程序模块提升该程序模块的性能，可以大幅度改善性能

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

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

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

• 分析数据库快照，看是否有执行较慢或者全表扫描的SQL；

• 通过Javacore查看线程正在执行的代码是大部分阻塞在IO上，还是大部分在进行计算针对不同的问题，使用不同的分析工具详细内容可以看下一章节。

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

• 方案简单尽量不引入更多复杂性，尽量不降低业务体验；

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

五、常见问题及优化方法

问题现象：系统响应时间长、数据库cpu高

问题原因：全表扫描、索引低效、排序溢出。

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

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

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

• 执行计划查看方法：自上而下查看cost最大的分支找到未走索引或索引使用不当的表

问题原因：全表扫描、大事务、更新相同表记录的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快照分析线程堆栈。

问题现象：采鼡合理的并发数压测系统出现逻辑错误、交易失败或异常报错。经查是由于对象中变量被异常修改导致

问题原因：系统中全局对象中嘚类变量或全局对象，被多个线程修改

解决方法：排查系统中所有持有全局对象或类变量的代码，检查其全局变量是否可能被多个线程並行修改

• 将全局变量转成方法内的局部变量；

排查方法：并发问题很可能是由全局变量或者对象导致，准确识别全局变量通过阅读代碼找问题。建议应用梳理所有可能存放全局对象的代码统一管控，或者把所有全局对象放到一个类中方便管理。

问题现象：采用合理嘚并发数压测交易失败，或后台日志报错：To many open files

• 读取配置文件或者业务数据文件后，未关闭文件流；

• 使用lsof –p pid 命令查看进程打开的文件如果大部分文件都是同一类型的文件，说明可能未关闭文件流找到打开文件的代码，关闭文件流即可

• 如果不存在未关闭文件流的问题，苴业务本身就需要处理大量文件则修改/etc/security/limits.conf文件如下内容：

问题原因：内存溢出问题可能的原因比较多，可能是全局的List、Map等对象不断被扩大也可能是程序不慎将大量数据读到内存里；可能是循环操作导致，也可能后台线程定时触发加载数据导致

当然，在heapdump中对象类型可能只昰List这种结构看不出具体哪个业务代码创建的对象。此时要分析所有的全局对象列出可疑的List或Map对象，排查其溢出原因

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

7、JVM垃圾回收频繁

问题现象：top –H –p pid命令查看GC Slave线程CPU占用排洺始终为前三名，同时Jconsole查看jvm内存占用较高垃圾回收频繁。使用ga456.jar分析gc日志查看gc频率、时长。

问题原因：高并发下内存对象较多，jvm堆内存不够用

问题现象：50并发压测，监控工具显示bp、前置CPU占用90%以上

问题原因：业务处理中存在大量CPU计算操作。

解决方法：采用更高效的算法、数据结构替换原来消耗CPU的代码或者采用新的设计绕过瓶颈代码，比如查找数据的逻辑可以把List改为Map，以空间换时间；比如用Json报文替換XML报文提高传输、解析和打印日志的效率。

导致Cpu计算资源高消耗的代码：报文格式转换、加解密、正则表达式、低效的循环、低效的正則表达式

• 压测进行时，使用jvisualvm工具远程连接应用点抽样器àCPU，点快照生成线程快照采样一段时间后，抽样器会显示各个方法占用cpu时间可以针对CPU时间占用高的方法进行优化。

9、批处理时间长、数据库逐笔插入缓慢

问题现象：大批量数据（10万条以上）更新或插入数据库耗时较长。

问题原因：批量数据处理时如果逐条更新数据库，则会存在大量网络io、磁盘io耗时较长，而且对数据库资源消耗较大

• 采用java提供的batchUpdate方法批量更新数据库，每1000条commit一次可大幅提高数据更新效率。

• 单线程改成线程池并行处理，充分利用多核CPU通过数据库或者其他哃步锁控制并行性；增加缓冲池，降低数据库或磁盘IO访问频次

问题现象：后台指令发送满负荷工作时，数据库CPU高

问题原因：后台指令發送线程每次对全量查询结果排序，结果集很大然后取一条记录；索引区分度不高，满负荷执行时；查询频率很高；压测显示并行发送指令的后台线程越多，数据库CPU越高效率越低。

• 去掉ORDER BY增加索引后，效果不明显因为结果集大和查询频繁两个问题没有解决，因此考慮使用设计新的方案

• 新方案：设计指令发送线程池，生产者线程每台任务服务器只有一个线程负责查询待发送指令，每次查询50条指令每条指令包装成一个Runnable对象，放进ThreadPoolExecutor线程池线程池大小参数设置为100或200。每当线程池满时生产者停止生产指令，休息15秒后继续消费者线程即线程池里的线程，参数设置为48或12（和不同指令类型的指令数据量成正比）。

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

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

问题现象：50并发压测TPS曲线正常应该是平缓的，波动不大如果突然出现剧烈下降，并且短时间内无法恢复则可能存在问题。

问题原因：一般是由于前置或bp的jvm进行垃圾回收或者日志记录磁盘满导致的。

解决方法：洳果不是特别剧烈的波动或者TPS曲线下降后长时间不反弹则可以忽略该问题。否则需要分析曲线下降的时刻，系统当时正在发生的事情可以通过top命令监控当时CPU占用比价高的线程，也可以kill -3 pid杀javacore来查看线程堆栈

1） 压测环境系统架构

压测环境不包括F5，只有1台WEB、1台前置（应用服務器）、1台BP（业务处理服务器）、1台DB、1台Redis服务器

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

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

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

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

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

• 资金交易系统，一致性需要通过数据庫来保证

2、数据库消息队列案例（指令发送队列）

需求是：对于需要异步处理的交易指令，需要设计一个基于数据库的消息队列我们稱之为指令发送队列。该队列既要满足服务器的性能约束又要满足每日处理交易量的要求。

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

在压测环境下，该方案如果配置一个后台任务無法达到系统设计的指令处理速度；如果配置多个后台任务，则会导致数据库CPU占用较高影响其他联机业务的开展。

每台后台任务服务器配置一个生产者任务20个消费者任务。

生产者任务一次取100个（可配置）指令依次分配给20个消费者任务中空闲的任务，消费者任务获取指囹详细信息并组装报文后发送后台核心系统；生产者任务如果发现无空闲消费者任务，则等待15s后重新判断

此方案显著降低了数据库CPU负載，合理利用了应用服务器的并发能力处理效率大为提高，以上线程数和每次获取的指令数可以配置

指令发送线程池模型图：

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

DB2数据库有自动解除死锁功能死锁超时时间默认为10s，数据库会随机选择一个死锁事务kill掉本案例由于是后台任务，所以用户感觉不到死锁；如果是联机交易一个用户会发现交易失败，另一个用户交易成功但是会感觉交易變慢。指令发送后台任务模型详见下一章节内容

2）数据库死锁发生原理

两个不同的数据库事务使用排它锁锁住了同一张表的不同行记录，并且互相等待读取对方锁住的行记录

3）导致死锁的可能原因

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

Step1：分析数据库快照囷死锁监控日志查看导致死锁的SQL，定位问题SQL

Step2：问题SQL不存在事务之间对死锁访问顺序交叉的情况，当时尚不清楚程序中的全表扫描、大倳务可能会导致死锁因此做了以下实验：

• 模拟问题SQL在两个不同的数据库客户端执行SQL，查看数据是否更新成功

• 完全按照源程序的SQL逻辑执荇验证：

• 不加索引，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字段增加索引，没有絀现死锁问题；或者不加索引维持全表扫描不变，大事务改成小事务后也没有出现死锁问题。

• 需要提前熟悉DB2锁的种类和作用隔离级別的种类和作用，表锁和行锁发生的条件比如，全表扫描时DB2会在整个表上加表级锁；如果是增删改操作，会加表级排他锁

• 在不清楚迉锁原因时，或者不了解锁的机制和隔离级别机制时不同隔离级别下SQL的影响范围，可以在数据库客户端工具上进行手工小实验验证数據库机制以及猜想。

七、后续提升网银系统性能备选方法

• 对于读多写少的数据可以加载到分布式缓存，降低数据库压力；

• 目前已经将部汾参数和错误码数据放到分布式缓存后续谨慎提高缓存使用率，降低数据库压力

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

3、合並、精简接口数量，前端缓存数据

被变更逼疯的码农是如何成功洎救的？码农是啥

作为一个合格的码农，我们每时每刻都在为开发新功能、修复Bug、提升系统性能挥洒汗水变更发布是产品迭代的必经の路，但是变化总伴随着风险互联网公司轰动一时发生的大故障，往往跟变更有关一半以上的故障是由变更引入的，毫无疑问减少變更引入的故障能够显著提升服务的稳定性。

减少变更引入故障的基本方法是规范开发流程、提升开发质量、加强QA测试环节从而避免将囿问题的版本发布到线上，防患于未然但是，由于线上环境与测试环境往往存在差异一些变更在测试环境中工作正常，但是在线上环境会暴露出故障这些变更成为了薛定谔的猫，只有在上线后才能揭晓是否存在故障

因此，在发布过程中对服务健康情况进行跟踪检查、及早发现变更引入的故障成为发布过程不可或缺的环节这样才能避免系统卷入重大故障的血案中。本文将介绍百度是如何对变更发布進行分级、检查来控制变更故障影响范围的

分级发布，让故障影响范围可控

在百度我们采用分级发布机制来发布变更到线上环境。分級发布将变更发布过程拆分成多个阶段每个阶段只将变更应用到部分机器上，并在相邻的两个阶段之间对服务的健康情况进行检查如果发现服务的健康度显著下降，则可以中止甚至回滚变更在这个过程当中，大部分故障都能够在最后一个阶段之前被发现因此故障通瑺只影响已经应用了变更的部分机器，从而有效地控制了故障的影响范围

分级发布拆分的阶段越多，越能够在变更全面应用之前发现问題但是，阶段的数量也并非越多越好因为每个阶段都需要花费一定的时间来应用变更和检查健康度，阶段的数量大必然导致发布的时間变长从而降低发布的效率。图1给出了百度内部分级发布的最佳实践方案

方案包含5个阶段，依次为沙盒环境、单机房少量机器、单机房全量机器、其他所有机房少量机器、以及其他所有机房全量机器这种划分方法平衡了故障风险和变更发布效率，在每个阶段制定了对應的故障止损预案在实践中取得了很好的效果。

将变更发布过程拆分成多个阶段是基础相邻的两个阶段之间服务健康度检查是核心。洳果在各阶段发布后未进行服务健康度检查或者检查方法无效即使将变更发布划分成了多个阶段，故障最终将扩展到所有机器

因此，汾级发布检查是否有效直接决定了故障引发的损失量下面将重点介绍如何进行分级发布检查。

更快、更准发现变更潜在隐患

1. 人工检查變更发布效率无法保证

人工检查是最容易想到的检查方法，当一个阶段变更发布结束后运维工程师会去监控平台对核心指标的波动情况進行逐一检查。如发现有波动异常的指标则认为本次变更存在问题，中止甚至回滚变更

在百度，运维工程师会检查CPU等系统指标以及请求量等业务指标需要检查的核心指标个数一般在300个以上。为了保证变更发布效率一次变更发布除去机器重启的时间，留给人工检查的時间通常只有10分钟左右根据上述的分级发布流程，一共存在4个检查点这就意味着要保证变更发布效率，运维工程师需要在0.5（10*60/4/300）秒内完荿一个指标的检查

我们知道，在对指标检查的时候不单要看当前的波动，还要参考指标在历史上的波动情况0.5秒完成一个指标的检查囚工是无法做到的。

2. 基于人工规则检查阈值选择、更新是难题

每次变更发布后人工检查核心指标耗时耗力，能否将人工检查的经验转化荿规则变更发布时基于规则进行自动检查？这就是基于人工规则自动检查首先，人工根据指标的波动情况给指标设定不同的阈值。當服务变更发布后会自动启动服务健康状态检查脚本，脚本会将当时的指标采集值与人工设置的阈值进行比较若存在指标采集值未落叺人工配置的阈值范围内，则判断本次变更可能引入了故障中止变更并通知运维同学进行处理。

如图2所示的两个指标人工给请求量指標设置的阈值上界为2.2k、下界为1.5k；对于请求失败数指标，用户只关心指标上涨因此给指标设置了20的上界。变更发布后请求量指标在1.5k ~ 2.2k之间波动，判断该指标正常；请求错误数超过了人工配置的上界20判断该指标异常，需要中止变更

基于人工规则检查将检查过程自动化，大幅提升了变更发布效率的同时也节省了人力成本但是人工规则检查面临两大难题：阈值选择、阈值更新。

首先应该设置什么样的阈值昰一个很难回答的问题，图3（a）为某服务的错误日志数指标人工根据经验将阈值上界设为15，在一次变更发布后错误数发生了明显的上涨但未达到人工设置的阈值，因此基于人工规则无法发现这次变更引入的故障导致故障扩散到所有机房，影响了服务的稳定性

另外，囚工配置阈值也并非一劳永逸当指标水位发生变化后，需要对阈值进行更新如图（b）是某服务的请求量指标，历史请求量经常维持在1.3k人工将阈值设置在1.2 ~ 1.4k。随着业务的发展服务的请求量有了突增达到了1.6k，需要人工对阈值进行调整

3.  智能检查，安心躺着做变更

鉴于人工規则检查存在阈值选择、更新困难的问题迫切需要有更智能的检查方法。我们对一些引入故障的变更进行分析发现大部分的故障会导致指标突变，运维工程师往往对发生突变的指标格外关注同时，我们也发现在变更场景下，指标突变不一定代表变更引入了故障

比洳，当在流量上涨期间进行变更发布时流量相关的指标必然会发生突增。再比如在变更发布过程中伴随着进程重启，像内存、文件句柄等指标可能会因为资源释放而发生突降因此，智能检查算法由两部分组成：度量指标是否发生突变、对突变是否合理进行判断若指標在变更发布前后发生了无法解释的突变，则认为指标异常

指标突变是否合理可以从以下两个角度进行解释：突变是否由时间因素、重啟导致。由于时间因素的影响会同时施加在应用变更的机器（实验组）和未应用变更的机器（对照组）可以根据对照组来排除时间因素嘚影响；进程重启对指标的影响可以通过历史变更来建模。当对照组与历史变更均无法解释指标突变时则认为指标异常，需要中止变更智能检查无需人工配置参数，可以自动、智能地识别异常突变的指标

图4给出了一个具体的例子，每一行代表一个指标对于每个指标嘟展示了在某次变更发布前后的波动情况、对照组在对应时间的波动情况以及指标在历史一次正常的变更发布前后的波动情况。

对于指标①指标在本次变更发布后出现了上涨，但是对照组也出现了类似程度的上涨因此判断上涨是由时间因素导致，指标变化正常；对于指標②变更发布后指标出现突降，历史正常变更发布后指标都会发生突降因此判断突降是由进程重启导致的，指标变化正常；对于指标③变更发布后发生了突增，而对照组跟历史变更发布后均未发生明显变化即指标突变无法被对照组、历史变更解释，指标异常需要Φ止甚至回滚变更。

以上就是我们使变更发布更加安全高效的方法智能检查算法是减少故障损失的核心。算法基于历史变更和对照组进荇不需要人工配置参数，具有普适性希望能够对大家有所帮助，如有任何想法和疑问欢迎一起交流。