随着银行业务的不断丰富、拓展,系统账户数量、交易总量及业务类型种类急剧上升,银行核心系统对高并发实时交易、业务峰值处理能力需求持续攀升。以前一个客户对应一两个账户,现在人民银行出文账户分类,一对十的情况都屡见不鲜,系统规模不断的增大,有可能超出交易系统最初设定的容量,因而商业银行承担的确保交易系统稳定运行的压力也越来越大。


核心系统是现代商业银行开展业务的基石。对于银行来说,核心系统的性能要求是最高的,银行系统群中对于核心系统的访问量以及并发数等指标都是远远高于其它系统,它的性能决定整个银行IT系统群的性能指标高低。由此也说明了,核心系统的性能优劣直接影响了商业银行业务的可用性与稳定性。


那么现在中小型银行面对业务量的急剧攀升,出现性能瓶颈时带来哪些问题:




系统资源总感觉不足,长期花费大量的资金用于更新硬件设备

· CPU  经常性100%
· DISK  I/O持续高位


系统经常性或者规律性的出现响应滞后、业务办理缓慢

· 业务高峰,系统响应滞后或超时,客户满意度下降
· 业务人员无法持续工作,业务办理断断续续,苦不堪言
· 后台批处理运行时间越来越长

核心系统越来越复杂,犹如潘多拉宝盒,无人敢碰

· 系统不出事就好,业务扩展举步维艰
· 系统运维人员如履薄冰


先来说说什么是系统性能。这个定义非常关键,如果我们不清楚什么是系统性能,那么我们将无法定位。系统性能问题是系统各个组件在正常情况下,处于瓶颈的组件过于繁忙而导致系统整体服务能力下降的情形,性能问题不及时处理可引发大面积的系统故障。


在此,系统性能提出两个关键性指标:


1.Throughput,吞吐量。也就是单位时间内可以处理的请求数,任务数。它以系统资源为对象的,系统资源的好坏直接影响了吞吐量的(理论)极限值。


2.Response Time,响应时间。也就是系统在处理一个请求或一个任务时的耗时。它是以某个请求为对象的,请求的大小以及复杂程度直接影响到响应时间的长短。


一般来说,一个系统的性能受到这两个条件的约束,缺一不可。例如,系统可以顶得住一百万的并发,但是系统的响应时间是2分钟以上,那么,这个一百万的负载毫无意义。系统响应时间很短,但是吞吐量很低,同样没有意义。所以,一个好的系统的性能必然受到这两个条件的同时作用。


· Throughput越大,Response Time往往会越差。因为请求量过大,系统太繁忙,所以响应速度自然会低。


· Response Time越好,能支持的Throughput就会越高。因为Response Time短说明处理速度快,于是就可以处理更多的请求。


总的来说,银行核心系统性能体现可概述为客户请求是否被快速处理,系统资源是否得到合理利用,系统是否能够连续不间断的运行主要三个方面。

    现通过实际生产运维结合核心系统运行的情况,探讨如何定位和分析系统性能瓶颈。


    当系统存在性能问题的时候,不是急于去翻查程序的代码,这个毫无意义。首要确认的是系统资源使用状况,看看系统的CPU利用率,看看内存使用率,看看系统磁盘I/O等。


    (1)CPU利用率:如果CPU利用率不高,但是系统的Throughput和Response Time上不去了,这说明我们的应用程序并没有忙于计算,而是忙于别的一些事,比如I/O等。


    (2)I/O繁忙度I/O和CPU一般是反着来的,CPU利用率高则I/O越空闲,I/O越繁忙则CPU利用率越小。关于I/O,我们要关注两个事,一个是磁盘文件I/O繁忙度和有无特殊热点盘,一个是内存换页率。这两个关键节点都会与系统性能息息相关。


    (3)应用程序如果CPU不高,I/O不高,内存使用不高,网络带宽等使用不高,但是系统的性能就是上不去。这说明应用程序存在了问题。比如,程序被阻塞了、可能是因为等哪个锁、可能是因为等某个资源,或者是在切换上下文等。

系统性能优化要有合理的取舍,要在各个相关因素之间取得平衡,调优的工作应从整体出发,如果对系统的调整只是集中于某一方面,那么就不可能达到优化系统性能的目的。


性能优化的任务就是要增加事务处理能力,通过提高吞吐量和缩短响应时间来提高并发处理能力。提高并发处理能力可以通过资源重复、时间重迭和资源共享的方法。


资源重复利用硬设备的多重设置,即增加相同的硬件的设备数量,使得这些硬设备同时工作,以提高系统的处理能力;


时间重迭是多个处理时间上错开,轮流使用同一设备,而不是增加设备的数量,典型的时间重迭方式就是流水线方式(错峰避锁);


资源共享主要釆用软件手段让多个程序按时间片来轮流使用同一套硬件资源,以提高利用率。


核心业务系统的性能优化措施根据如上所述,主要包括硬件、操作系统、应用软件等优化。


(1)硬件组件问题

常见的处理办法是对硬件进行扩容或者升级可以快速解决。 比如对存储系统的更新换代,可能会带来交易相应时间的大幅度改提升;对服务器增加CPU数量、 扩充内存等。


(2)系统软件问题

常见的处理办法是升级为新版本或安装新补丁,或者调整系统配置参数。系统软件升级环节看似简单却可能引起兼容性问题, 其影响范围是全系统级别的,需慎重并经充分测试后,方可部署实施。


(3)应用本身问题

应用问题多属设计问题,常见的做法是对设计拙劣的应用代码逐步优化。应用代码的优化可能是个长期的任务,因为导致性能不良的应用设计环节可能不止一个,而是一个模块或是一个系统机制等。 且伴随数据规模和并发访问数的增长,会抹去一部分性能调优的效果。具体应用的问题,针对各行的处理措施要结合生产实际运行来设计。