案例分析总结连载：第六章

 

案例分析总结

 

很多大型系统由于性能问题出现业务运营瓶颈，此时再对系统进行优化难度就相当大了。下面向大家共享一段经历，这是在一个银行信贷系统优化项目中，我和伙伴们所遇到的困难和挑战，借此也为大家提供第一手性能优化材料。开始部分介绍这个信贷系统的负载情况及WLM等应用。

2010年5月14日   笔记整理                            地点：广州

刚迈出大厅，前来接机的银行工作人员，就一左一右把我“架”上了车直奔银行的机房。

银行信贷系统通常是非常稳定的，但是这类系统一旦出现性能问题，往往都会非常棘手。信贷系统数据库存放的是银行的所有客户资料数据和贷款账户数据,其对安全性、可靠性的要求远远高于其他行业; 另外，由于信贷系统的在线用户数量极大，数据更新频繁，逻辑处理复杂, 因此对数据库的事务处理能力要求很高。

我喜欢以业务为切入点分析问题，而不是立刻扎入日志或代码的海洋。该银行信贷系统的软硬件架构由信贷应用、中间件、DB2数据库、AIX服务器、IBM企业级存储等部件构成，性能瓶颈的定位和解决过程都比较复杂。目前主要的问题集中在用户交互响应时间达不到预期标准——在业务繁忙时段无法做出及时响应，特别是在做定时批量款项时，发生过两次系统宕机，损失惨重。

之前，银行的DBA就系统性能问题曾小范围调整过，但是收效不大，看得出他们有明显的挫败感。我心里很清楚，此刻的他们既希望有转机，又对新提出来的方案本能地持怀疑态度。我决定小试身手，先改善定时批量款项模块的性能，为后面的顺利协作培养认同感。从业务人员那里了解到，这个模块以前是基于Oracle的DBMS_JOB实现的，后来迁移到DB2数据库。当时数据库迁移人员使用存储过程实现了这个模块，会定时调度执行批量贷款逻辑，这种实现机制会大幅度地占有资源从而影响其他应用的正常运行。我提出基于WLM的设计方案建议，银行方面表示认可。之后，运维人员根据执行方案为此模块定义了工作负载、阈值、服务类，以及对资源使用的优先级等。经过一周测试后，证实这一模块带来的性能瓶颈被大大缓解，而之前对我不太信任的DBA们也开始对我感兴趣了。

不过，系统还是存在明显的CPU和磁盘瓶颈。像往常一样，在制订性能优化方案之前，我开始向大家介绍系统化的优化思路，并连续两次组织了“PAT方法学”培训。优化策略的四个步骤大家都理解并认可了，时机已到，我开始着手做信贷系统优化的“术前准备”。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25714482/viewspace-703617/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25714482/viewspace-703617/