DRP项目因为系统性能“四进宫”何解

1、DRF项目因为系统性能“四进宫”何解已经有三个月时间没有到温州了，正好这次有机会出差到温州，可以和温州的一班老朋友们好好聚聚，同时也开怀畅饮，边喝边聊了，因为大家一直都不缺乏深入交流的话题。这不， 人还没有到温州，“温州IT主管联盟”的“老大”一老胡就抛了一个案例，说是要给大家看 看，再一起帮着参详参详的：伴随着DRP项目的推进，软件方的顾问也逐渐撤出了，系统的运营自然也就成了企业IT部门的任务，而随着DRP系统的不断深入应用， 其它信息系统的不断上线，企业信息化程度的也越来越深，企业对于软件应用性能的要求也就越来越高，就需要对IT系统进行升级扩容等全方位的改进。从技术角度来看，在升级改造过程

2、中，比起全新信息化建设的困难度，实在是有过之而无不及。这类的因系统性能问题而升级改造的，不成功的案例多于成功的案例。让我们来看一下这个因系统变慢而”四进宫”的案例。原由：系统的响应时间慢，就是系统的升级的主要原因！软件平台：操作系统： Microsoft 2000 server数据库： Microsoft SQL server应用软件：行业内成熟的DRP软件，单机运行硬件平台：服务器：DELL （2个CPU 2GB的内存，和18GB的硬盘2个做镜像）磁盘阵列：DELL的220S SCSI盘阵（使用 18GB的硬盘14个做RAID-5，共250GB）经过两年的上线使用后，算是成功上线使用， 但是

3、开始有用户反映这个系统的响应时间越来越慢，希望信息中心可以提升系统的性能。信息中心和几个供应商的会诊后，确认是硬件指标太低，造成性能太慢。硬件慢，简单！只要有银子就可以解决。销售商介绍更高规格的硬件设备，于是把原来的设备转成其他的应用上，这个主要核心系统全部采购更新的高性能指标设备。第一次升级方案：购买高性能指标的服务器提高服务器的性能指标: 换服务器，把 CPU 2个变4个，主频1.8变成3.6,内存2GB变4GB换存储设备，SCSI盘阵太慢，换成2Gb Fibre光纤盘阵，加上2Gb的光纤交换机，采用最 新的SAN存储结构技术，采用 DELL推荐的中小企业用的盘阵 AX150 （双控、50

4、0GB SATA硬 盘7个）共3.5TB的容量，连数据备份一并解决。真划算，价格也不贵，总价在30万以内，在原来的预算内，有银子真的很好用！兴高采烈的迎接全新设备的，好像娶媳妇一样，信息中心上上下忙了大半个月，从培训、安装硬件软件、倒数据、系统测试、系统切换，连续加班好几天。总算把它侍候好了。系统上线了，和供货商一起聚聚，喝喝小酒，联络感情，以后好配合！三个月过去了，业务端反映，系统速度好像没有什么改善，甚至还慢了。财务部门反映每个 月的结算，速度和以前差不多。第二次升级方案：修改软件硬件已经提升了，有问题可能就是软件问题， 要软件商进行二次开发，修改软件。软件公司 因为慢的问题，收不到开发费

5、用，效果也就有限了。这又加班好几个月的时间， 改善不明显。软件公司找了一个高人，检测后，确定还是硬件问题？问题又推到存储上！第三次升级方案：升级盘阵上的Firmware服务器的工程师进行了盘阵上的操作系统版本和补丁，不见效果，和存储厂商的资深系统工程师，再继续找问题。最后换了一个高级技术经理，一看，你这个AX150盘阵规格太低，只适合做备份，不适合做 OLTP应用，应该使用更高档的全光纤盘阵，应该就没有问题。第四次升级方案：更换 4Gb的光纤盘阵现在是2007年，主流产品都是4Gb的光纤，于是更换更高指标的存储设备 CX3-20,带宽是 4个4Gb,共16Gb的带宽，盘阵内存是 4GB硬盘使用

6、300GB的4Gb纯光纤硬盘8个，服务 器上加两片4Gb的HBA卡，更换4Gb的光纤交换机。服务器的内存增加到 8GB.大半年过去了，听说系统的缓慢又出现了!心疼吗？白花花的银子这样来花！那么在这个升级的案例中，问题出在哪里了?上述的问题，经老胡一抛出来，就引起了大家的热烈讨论， 因为这类的问题在各个企业都曾 经碰到过，就算目前暂时没有碰到的，以后也会碰到，总之，这是任何一个企业都绕不过去的问题。正好当时手上上有事情， 没有怎么深入思考这个问题， 回过头有时间静下心来的时 候，就觉的这个问题值得好好研究。仔细分析上面的案例，其实没有给出一个相对客户的数据，说系统慢，是在操作系统、数据库、多少的

7、服务器端带宽、多少个并发用户数、客户端PC配置等情况都未知而由业务部门的使用人员发出的呼声。在这里，我觉的其实是可以根据用户的操作类型来区别一下的，系统性能应该包括两部分：1、OLTP（On-Line Transaction Processing，联机事务处理）操作：用户操作单据时，包括新增、修改、删除操作，类似的这种事务性操作应该要求响应比较及时，用 户可忍受的等待时间应该是在5秒钟以内。2、OLAP（ On-Line AnalyticalProcessing，联机分析处理）操作：而在于进行查询与统计操作的时候，由于用户对于查询的数据不同，其心理预期也是不同的，预期的时间可以从5秒钟到15分

8、钟不等，毕竟查询的数据量不一样，所需要的结果返回时间也 是不一样的，这一点用户应该是可以理解的。那么，我们要分析的问题主要就在事务性操作上，要求操作响应时间在 5秒钟以内，这应该是我们的一个最基本的目标。也就是说，我们目前要分析的主要就是OLTP的性能。由于OLTP性能会涉及到非常多的因素，包括服务器、DRP软件系统、网络状况、客户端 PC机配置、数据库、用户等，针对这些情况，我们用下面的因果图进行分析：针对上述的因果图，我们可以根据上述原因进行逐一分析与排查，并制定出具体的 应对方案：毕竟所有的硬件及网络设我有针对DRP系统的架构进 友 可 以 参 考1、DRP系统：DRP系统本身的原因，也

9、是系统速度慢的根源所在,备都是为DRP系统服务的。a）从软件架构不合理上来考虑， 在前面的一篇文章中,行 讨 论 的， 有 兴 趣 的 朋(http:/blog.csd n.n et/Drate/archive/2007/07/17/1694698.aspx)b）而对于大量使用数据感知控件，这应该是程序员的错，因为在开发小应用系统的时候，如使用DBGRID这样的控件，一次显示整个数据表的内容，如果数据条目在100-1000条，可能速度不会有太明显的差异，但如果数据条目是在 1000条与100万条之间比较的话，那肯定就不是同一个层面上的了，所以进行数据显示的话，直接与数据源关联， 有可能会引起资

10、源耗尽的情况还没有能够显示出你所请示的内容。C)习惯性全表数据显示， 这也是软件开发者在进行开发时没有注意的问题，因为性能问题都是在有了大数据量的时候才会显示出来的，开发期间由没有大数据量， 开发人员也意识不到，所以进行提供用户查询功能的时候，基本上不会用限定条件，或者也不进行数据分页显示，导致数据库服务器的数据请求量直线上升。2、 网络：网络与系统的稳定性是直接相关的，特别是目前的DRP系统中，采用的都是数据 大集中的方式，所有的数据请求、数据处理都是要通过网络来完成的。 网络的问题可以归结 为以下几个方面：a) 服务端的带宽，目前一般有ADSL 2M 10M 100M的光纤可以使用，系统数

11、据慢， 可以通过测试看服务器端的带宽是否足够。b) 电信与网通的问题：这是中国特色的问题，由于网通主要在北方，电信在南方，所以终端的线路情况各不一样，特别是进行跨网络访问的时候，速度会是奇慢，而且网络会经常莫名其妙的断开，现在很多企业在机房里各拉一条网通与电信的光纤就是这个原因。c) VPN 、防火墙问题，为了增加网络的安全性， VPN接入是目前DRP系统常用的一 种方式，防火墙也是必不可少的，可是如果VPN或防火墙的性能不够的话，也将会使网络阻 塞严重，系统自然也就慢了。d) 客户端带宽：客户端带宽应该在目前来说，问题不会太大，因为现在ADSL的普及，很难再找到使用 MODE拔号上网的了，就

12、算是现在的无线网络， 其速度也远远要比 MODEM 拔号上网要快的多。e) 网络设计不合理： 这个问题是会是一个非常隐秘的问题， 女口：由于企业的网络管理员水平有限，没有对网络内的计算机进行分网段管理，容易出现“网络风暴”，导致交换机进行频繁的垃圾数据交换， 交换机也是经常性死机， 自然系统的速度会下降了。 又如网络 内存在病毒或者是木马，在网络内发送大量数据包，或者甚至是DoS(拒绝服务攻击)。3、服务器：一般包括以下几种类型的服务器，一是数据库服务器，二是指应用服务器，三 是存储服务器，在这里我们不进行特指。a) 服务器总线IO:在服务器领域，数据是需要进行密集交换的，而IO总线的频率基本

13、上决定了一台服务器的性能，所以，为什么不同服务器之间的 CPU内存可能都差不多，但价格相差很多？同样性能也有很大差异呢？关键就是在于服务器的总线IO能力了。b) CPU 性能：目前的PC服务器，一般都是能够加载多颗CPU的，是选2颗还是4颗或者是8颗，那就是要看应用的情况了，一般来说，在CPU的负载在80鳩下是比较正常的，因为如果有一个峰值的话，CPU的负载就马上会到 100%上的。c)内存不足：内存也是和CPU一样，可以在服务器上进行扩展， 根据需要进行配置,这个问题也比较明显。d) 磁盘10问题：磁盘10,这里有可能是用磁盘阵列柜，也有可能是光纤存储，如 果在用阵列柜的话，就要看一下是否是

14、这里的问题了。e) 服务器间网络带宽问题：由于存在着数据库服务器、应用服务器、存储服务器，这几个服务器之间的带宽是否能够在1000M?或者是直接用光线网络进行数据传输？这也是根据应用情况进行考量的。4、数据库：a) 数据库系统配置不合理：DBA在这里就起到非常大的作用了，特别是像ORACLE这样的大型数据库，一个好的DBA可以将数据库系统的配置与软件系统达到最优化组合，性能的提升也是非常明显的，而如果是一个菜鸟来做的话，估计只会按照安装的默认配置来 运行，系统性能相差的就远的去了。b) 数据库索引及优化：数据库索引与优化，如果DRP软件商有对数据库非常熟悉的软件架构师，会对数据库的索引进行优化

15、，以提高系统的效率，但说实话，目前更多的软件商将精力放在了前端的界面展现上，而不是数据库的“内功”修炼上。c) 数据冗余：合理的数据冗余可以增强系统的性能， 这是谁都知道的，但有的系统却是过滥，将数据库设计的过分冗余了，导致数据库成了吃硬盘的“杀手”，数据库一直不停地高速膨胀，系统性能也就直线下降了。d) 存储过程与触发器：存储过程与触发器，这应该是属于业务逻辑层来干的事情，如果一个好的系统，我认为应该是不在数据库层面来执行业务逻辑的，所以，一直比较抵触这两个，特别是触发器。5、 客户端PC配置太低：比较容易理解，386的机器跑WINDOWS XP老牛拉破车吧。6、用户:a) 用户心理预期较高

16、：由于用户可能之前有用过类似的系统，由于数据量较小，或者之前用的是小系统， 有一个习惯的问题；或者就是一个心理预期， 认为一个新系统的话总 会有算改进的，所以就把新系统想的很美好，结果实际上不是这么一回事的时候，自然就有落差了。b) 并发用户数量：并发用户在10个与100个的时候，系统的速度，对于硬件、网络设备的要求肯定是不一样的，因此，在做评估的时候也要将这个因素考虑进来。c) 用户无意义操作：用户经常性无意识地刷新数据就会对系统的性能造成影响，但用户可能并没有意识到，因此，这一点需要在用户培训中提醒进行归避。针对上述列举的问题，需要做出一个详细的性能测试表格，对以上各项数据进行测试，找到问题的瓶颈在哪里，并针对问题的瓶颈，有规划性、针对性地部署升级计划。同时需要IT部门定期对上述性能进行评估，以便IT部门能够及时发现