如何应对银行交易系统性能下降

申请免费试用、咨询电话：400-8352-114

银行交易系统性能下降,是由于后台的数据规模、应用的逻辑复杂度、客户并发的访问数在逐步增加，日积月累就会跨越最初的设计容量，从而遭遇性能瓶颈。

性能问题的范围

银行交易系统又称为银行OLTP系统（On-Line Transaction Processing），即银行联机事务处理系统，其基本特征是客户交易数据实时发送到银行后台主机进行处理，并在极短的时间内返回响应。银行交易系统一般都是实时系统(Real time System)，性能至关重要。

银行交易系统包括核心交易系统、信用卡系统、大前置系统、网上银行、电话银行、手机银行、第三方存管、银基通等。

银行交易系统性能管理可概括为: 客户请求是否被快速处理、系统资源是否得到合理利用、系统是否能够连续不间断地运行三个方面。

决定银行交易系统性能的往往都是后台的Server系统。从性能分析的角度，后台系统大致可以划分如下几类: 硬件组件有服务器主机、网络等; 系统软件包括OS、中间件、DBMS等; 应用软件如联机应用、批量应用、定时应用等; 系统架构是指组件之间的协作方式，比如应用与数据库分离运行还是单机运行等。

这些组件都可能成为银行交易系统潜在的性能瓶颈。不同的是，硬件组件与系统软件组件的性能瓶颈容易被发现，也容易被快速处理。而应用软件和系统架构方面存在的性能瓶颈不容易被发现，发现与解决的周期会很长。

需要说明的是，系统性能问题与系统故障有所不同。故障往往是由于某些组件异常导致交易系统部分或整体无法正常工作; 性能问题是指在系统各个组件正常情况下，处于瓶颈的组件过于繁忙而导致系统整体服务能力下降。性能问题得不到及时处理也可能引发系统故障。性能问题就像亚健康，而系统故障就像患病。

银行交易系统的性能问题不明显时，客户和交易柜员基本察觉不到系统的异常。当性能问题逐渐积累并且爆发之后，交易系统的客户就会明显感觉到异常，客户满意度也随之下降。

主动发现问题

当银行因交易系统性能问题产生客户投诉后再开始应对处理，就比较仓促和被动。所以最好是能在日常的运营维护中发现系统的性能问题——当问题还没有影响到业务本身时，处理起来会比较主动。

利用监控工具和报警规则，找到问题的征兆。在银行交易系统运行中，大多数性能问题可以从操作系统、网络、数据库、中间件的细微变化中察觉出来，例如内存过度消耗、CPU过高使用率、进程频繁启动或数量过多、数据库会话过于繁忙、中间件队列变长等。所以常见的监控对象通常是: CPU、磁盘I/O、网络、文件系统、进程、系统日志、数据库负载和中间件队列等。

可以使用成熟的商业监控套件、也可以使用自主编写的监控软件、性能检测脚本或者软件自带的工具，比如: Quest、HP OVO、IBM Tivoli等。操作系统自身也有丰富的系统管理工具可用。对特定的系统软件，比如Oralce、Tuxedo、Informix等软件系统，需要有针对性地引入监控工具并建立报警规则。以Informix数据库为例，监控工具除了自身的onstat命令外，IDS11会自带图形化的监控工具Open Admin Tool。第三方的监控工具有台湾库柏的DBSonar软件等。在应用系统监控方面，应该有对应的监控工具。简言之，如果全部性能组件都有相应的监控工具和报警规则，则比较有利于快速发现问题。

收集各组件的性能数据。银行交易系统出现性能问题的时间段可能很短，也可能没有规律。为了方便专家分析，在交易系统出现性能问题的最短时间里，应尽可能收集该时段中各性能组件的运行数据，不管问题发生在操作系统、存储、数据库、应用服务器还是WebServer等; 我们需要借助软件工具来收集有用的系统性能信息，直接在每个被监控的系统中搜集端到端的准确信息。

应高度重视数据库系统运行信息的收集。很多情况下，数据库运行信息收集需要一些辅助手段，比如informix在版本11之前的性能监控不够完善，获取会话信息比较困难，即使借助DBSonar等工具获得的信息也可能是不准确的。往往还要借助一些其他的工具或脚本来收集数据。

对应用方面的数据收集还可以开启报文记录功能，利用存储系统对数据库和文件系统做快照，能方便重现问题，并且可分析和验证解决方案是否有效。

定位性能瓶颈

发现银行交易系统的性能问题之后，需要定位性能瓶颈。可以遵循这种查找顺序: 从近期有变更的组件到近期无变更的组件，从应用类组件到系统类组件，从软件组件到硬件组件。

请银行交易系统的主要相关厂商协同分析是好办法。明确供应商责任有利于快速解决问题。在各供应商收集的性能信息基础上进行实时和历史分析，可大大缩短问题查找和等待的时间。各厂商一般都有丰富的性能问题案例库，可以结合性能问题特征，采用分段排除法，最后定位系统的性能瓶颈出在哪里。

实践当中应注意，性能瓶颈所在环节也许并非是触发性能问题的初始原因。很多情况下，应用本身的设计缺陷会造成数据库过于繁忙。有的数据库的BUG也可能造成数据库服务器CPU利用率过低或过高。不同的原因也许会造成相似的性能问题症状。

解决性能问题

解决性能问题可以参考专家建议和方案，有选择地进行实施。实施前需要进行反复的验证和评估，最后在现有方案中确定最优的解决方案并进行实施。不同性能组件的解决方法有一些常规的处理方法:

硬件组件问题: 常见的处理办法是对硬件进行扩容或者升级，可以快速解决。比如: 对存储系统的更新换代，对服务器增加CPU数量、扩充内存量、升级存储光纤卡等;

系统软件问题: 常见的处理办法是升级为新版本或安装新补丁，或者调整系统配置参数。

应用本身的问题: 应用问题多属设计问题，常见的做法是对设计拙劣的应用代码逐步优化。下列的做法一般有利于交易系统性能的提高: 交易系统的日志采用异步方式记录，优于同步方式记录日志; 交易事务小型化能减少锁冲突; 记录高开销的SQL，分析SQL的优化写法等。

系统架构的问题: 交易系统在架构设计之初就应将灵活性、可扩展性纳入其中。当某个性能组件成为性能瓶颈时，只需要在配置上增加同种组件的数量即可，方便快捷。拙劣的架构可能由于不具备可扩展性而成为性能瓶颈，引发性能问题。