银行核心系统的性能分析，我的一点思考

说出了银行业普遍遇到的问题，问题很突出很棘手，遇到问题很难短时间定位。目前实际银行IT系统性能问题确实有如下的几个问题点 <网络传输性能、应用网络性能、应用服务器本身的性能、数据库服务器的性能、存储系统的性能等。>

归纳起来就是 一个大的视图就是 硬件+软件+业务

硬件 三大块 主机 存储 网络

主机方面可以说现在不管是X86还是UNIX服务器配置都相当豪华。目前遇到性能很少出在这个层面。银行在硬件购置上都很舍的投入。

网络设备似乎在银行业成为性能瓶颈点似乎很少，毕竟网络本身快速发展，已经不是整个IT环境的一个瓶颈了，更多在于业务系统本身对网络本身的特殊配置了

存储方面，在实际的工作中，存储作为相对封闭的一个系统，其采购的初期就已经决定了其最大性能。即使一个存储规划的非常好,也不一定能够满足日益增长的业务发展驱动下。对IO的要求越来越高，存储很容易不堪重负，即使优化也很难摆脱28法则。存储硬件故障本身对IO影响因部件的重要性而异。大多遇到性能问题很多来自其本身。

软件 DB 中间件 等

db和中间件 由于是软件，设计的DB优化和数据库本身扩展性 需要专业人士进行详细的规划。这里经常出现问题。东西都一样，配置的人不一样效果不一样。

业务 具体应用或者代码级别了

每个业务系统应用开发商在彼此对接开发，版本更替等遇到可变的因素的太多，这里更容易出问题。但是问题定位起来相对麻烦.

分析的很好，我们也在考虑把数据库的ASM盘组做分级处理，目前我们能通过工具分析出什么时间哪些盘存在热点，之后需要考虑是用保守的分层技术引入SSD硬盘，还是直接接入一个全闪存阵列

非常赞成，就像解释围城的那句话，城里人和城外人。其实搞运维的人，高运维的思路，搞运维的运筹帷幄，都是城外的人理解不聊了。当时说的是真的运维，而不是大众理解的网管。

完成一个I/O流主要经历过的节点有HBA，FC网络，存储前端口FA，存储缓存、存储后端口，物理磁盘。而很个过程中最耗时的是物理磁盘。

存储阵列的缓存的大小和处理方式直接影响到I/O流的性能，也是定义一个存储阵列优劣的重要指标之一。

I/O的处理速度通常会远离理论值，原因多个并发量较大而造成的队列延迟。

优化I/O的方式可以从多个节点入手，而最显著的效果是提升物理磁盘的速度。因为存储阵列会把尽可能多的数据放入缓存，而当缓存用满以后的数据交换则完全取决于物理磁盘的速度。

适当选用合适的RAID级别，因为不同的RAID级别的读写比例大不相同，可能使得物理磁盘处理耗时几倍增加。

所以选择热点数据分层可以很大一部分的优化存储性能，全闪存存储对特别的重要的系统来说可以一试。

楼主分析的很细，其中提到了主要困难是数据库层的热点竞争问题，我觉得说白了，造成热点的原因主要就是锁竞争以及IO处理速度问题，闪存都是从IO响应速度来解决的，锁竞争则需要从应用来调整，但很多时候业务应用是无法拆分的，确实只能从IO相应来处理。这也就是为什么很多银行的核心都采用大机来解决，因为大机处理IO是独立处理的，性能会更好，相应速度更快，还有就是因为银行都在大机上开发了好几十年了，一下子迁移很有难度。所以，从技术角度分析，目前还是离不开基础架构硬件的性能提升。

对银行系统，我不赞成激进的做法，闪存盘的引入还是做成缓存比较好，性能重要，更重要的是稳定性

首先，闪存解决了高IO响应的问题，这个机械硬盘无法达到

其次，闪存的成本并没想象中的贵的离谱，因为不用通过复杂RAID来提高IO吞吐量，这又避免了一些RAID的BUG

最后，闪存的耗电量是机械硬盘望尘莫及的

此文观点非常赞成，有整体全局和系统的思维，才能运筹帷幄。

IO性能问题确实不好解决，目前我们就遇到核心系统数据库（informix）的IO问题，找了所有相关厂家来找原因，一直没有解决，主要体现在刷脏页的速度在业务繁忙时段会大大降低，最后为了解决这个问题只能把lru的值降低来让性能数据好看一些。但是仅仅是治标不治本的方法。

我非常赞同这个观点。分析的非常专业，也非常客观。