• 博客访问: 8552
  • 博文数量: 4
  • 用 户 组: 普通用户
  • 注册时间: 2009-11-08 20:50
个人简介

暂无介绍

文章分类
文章存档

2011年(1)

2010年(2)

2009年(1)

我的朋友

分类: Linux操作系统

2010-01-28 19:25:17

这篇文章是对《BIEB六人行活动》挑战企业IT系统焦点问题的第一季:拯救陷于性能瓶颈的项目 使得业务重新顺畅运转 的中有关性能优化的小结,不足之处,不吝赐教。

案例是一个B2C的主营音像图书制品的公司的B/S架构的CRM系统和网上订购系统,1台Web服务器运行CRM和网站,1台DB服务器与之对应;1台web服务器运行用户社区,1台DB服务器与之对应;操作系统都是WindowsServer2003,数据库是MS SQLServer2000,采用ASP.Net开发应用系统,采用MS IIS6部署网站。随着客户和业务量的增长,一是Web访问量增大了(吞吐能力瓶颈),二是系统反应速度降低了(反应速度瓶颈)。

目前很多B2C网站应该都是这样的架构,也会碰到相同的性能问题。

在进行性能调优之前,首先要做的是对当前系统运行状况的摸底,即搞清性能瓶颈的根源所在,简单的说“一个查询要花2-10分钟”只是描述瓶颈的现象;要找到根源所在可以从以下几个方面寻找:
一是在生产环境上打开性能计算器(Performance Logs and Alerts),从
1)ASP.Net反应和处理效率 2)SQLServer的CPU负载和效率和IO负载和效率 等方面进行监控,获得峰值情况分析。
二是打开SQLServer的SQL调试跟踪器(Profiler)跟踪SQL执行语句,获得执行语句的TOP N :最耗时的、最好CPU资源的、最耗IO资源的等等。
三是审查应用程序代码,找找那些效能低下的代码写法。

(以下是从itpub上搜到的有关性能计数器和asp.net提高性能的帖子:
常用性能计数器:http://www.itpub.net/viewthread.php?tid=690634
监测SQL2000下的IO瓶颈http://www.itpub.net/viewthread.php?tid=719713
提高ASP.net性能http://www.itpub.net/viewthread.php?tid=599804
当然网上有关这些知识性介绍很多的)


设计性能调优的方法,既要找对方向锁定关键点从而解决问题,又要能节省成本。性能瓶颈的首要原因通常都是:数据量大了。所以考虑怎样把数据量最大程度的减少掉是关键。成本分两种:投入的人力和时间以及花在购买软硬件上实实在在的银子。下面分析几种可行的思路。

1 SQL优化
  针对分析出来的TOP N:
  分析SQL语句的执行计划,看看是不是有没有命中的索引,是不是有全表扫描等。针对数据量大的表,建立相关的索引;(当然索引不是越多越好的,因为索引也要空间,更新插入删除都会更改表上的所有索引,这个也是要花时间的)
  分析SQL语句的执行计划,看看是不是有些比较耗时的语法,比如:滥用join,where条件中字段的顺序会影响执行计划中中间步骤筛选出来传给下一步的结果,适当考虑使用子查询,join的数据量超过一定级别后原先的循环join可能需要升级为哈希join等等。
   实现的业务逻辑,看看是否可以用更简单的方法实现原来复杂而耗时的sql语句。
   (SQL优化需要长期不懈的跟踪和调试,因为数据量的变化,可能导致更多耗资源的SQL出现,可能导致原先的优化方法不再奏效)

2 读写分离。
这是比较容易操作的方法。
在一个库上读写,当数据量大了,并发查询和更改变多了,一来容易死锁(SQL2000下很容易锁升级,表锁很容易造成死锁),二来建索引不方便(索引少了,查询可能慢了,索引多了,更新删除插入可能慢了,而且更新删除插入很容易导致索引的碎片泉涌不息)。
所以将尽可能多的“只读”从“读写”中分离出来是很必要的,数据库上的操作单一了,优化也容易做了。
可以分成一个主交易库+若干个只读库(通过订阅方式同步)。这样:报表方面的应用、产品主数据、给社区使用的用户数据以及其他可以通过只读实现的应用都可以访问只读库,针对只读库可以根据具体的应用做相关优化。而交易库的读会降低下来。
另外一个层面是数据文件的分离,将IO访问频繁的数据库文件放到单独的物理磁盘分区上。比如:可以将tempdb放到单独的物理磁盘上(因为tempdb是比较耗IO资源的且访问很频繁的)并且将其数据文件初始大小设置足够大。可以把交易库的数据文件放到一个单独的物理磁盘分区上。依此类推。

3 数据归档(Archive)
这是最重要的方法。单独一个交易库的数据量随着时间推移会一直增长。可以按照时间的先后把历史的数据放到专有的归档库(ArchiveDB)上,而交易库只保留足够短时间内的数据。CRM和网站系统,通常订单和账户交易的数据以及客户和客户地址数据时巨大的,订单和账户交易数据都是基于时间轴的,可以进行归档;而客户和客户地址,也可以根据一定的规则和需要做一定的迁移。社区或BBS,帖子那是也可以按时间来归档的。
当然,数据归档是一个跟业务逻辑很紧密的活动,需要仔细研业务应用对数据的使用,从而制定相应的数据归档策略。可以编写一个job每天来做数据归档。

数据归档的另外一种方法是数据表的分区(SQL2005和2008都支持分区了),它可以使你的应用保持原样,只需要根据给定的字段做为分区的“路标”,查询引擎帮你来查找到相关的数据。很关键的一点是:保证应用系统中所有的基于这个表的查询都使用了你分区的这个“路标”,否则这个查询可能很致命。

到底使用哪一种,需要根据实际的业务来判断,至少在2000的时代,人们已经使用第一种数据归档,而且也能处理千万级以上的数据。相比较而言:一个查询涉及一个表所有的数据的情况还是很少的。


4 硬件升级
这是提高单机处理能力的办法。软件性能提升终有限度,必须要用硬件来提升处理能力。而且硬件也是保障系统稳定性和可靠性和高可用性的关键。但是如果不考虑之前的优化方法,而直接优化硬件,实际的效果可能并不乐观。硬件升级可以从这几个方面:1)CPU和内存 2)硬盘 3)带宽。
CPU和内存:现在64位的CPU已经很普遍,而64位的CPU再加上64位的OS:WindowsServer2003/2008,可以使用32G的内存,配上64位的SQLServer2005/2008,处理能力会特别强劲(为什么?内存大了,读入的页文件多了,按照最近最常访问规律,访问磁盘的次数也会少了,内存加大相当于数据缓存起来的很大;另外CPU性能提升,单位处理时间会相对减少的)
硬盘: RAID那是必须的。为什么?安全可靠(多镜像不怕坏区)和高速(多磁头并行数据读写)。具体的请查阅RAID的介绍资料。
带宽:两个方面,一个是应用服务器连接数据库服务器的带宽(光纤???),一个是数据器主板的总线带宽。

5 垂直分割和水平分割
数据分割垂直分割最后讲是因为成本可能是相当相当高的。因为我们是针对一个已有系统做升级和性能调优,而非重新开发一个新系统,数据分割和垂直分割我想无异于重新开发一个新系统,它们需要分析人员厘清所有业务流程中数据的使用情况。

现在的Web2.0的网站有许多实现了垂直分割,比如根据客户的id将客户分流到不同的机器上完成各自的对立的完整应用,之所以实现容易,是应为客户的相关数据彼此之间并没有太多的影响。但是面对B2C这种带有明显的流程导向的,在有些环节需要将所有客户的数据汇总处理,比如订单的库存分配和订单的发货等环节,需要考虑所有客户数据的订单处理情况,要实现垂直分割,还是挺费脑筋的。

针对流程复杂的应用,采取横向的功能的水平分割还是容易的,即按照功能把应用分拆开来。
比如:面向终端客户访问的网站订购的Web服务器、面向内部用户的CRM的Web服务器分离开来,把客服呼叫中心使用的CRM服务器和其他后端支持部门使用的CRM服务器分来开来等等,这种分拆对硬件本身的要求不是很高,而且可以采用负载均衡技术来实现扩容。当然能这么分的前提是数据库服务器支撑住了应用。

就这些了,主要是从性能优化的角度,更准确的说是从数据库的角度来谈的。

以下是得奖感言:
感谢小李同学提供的案例,感谢itpub组织的本次活动,感谢贝贝、童馨mm,感谢XXTV...感谢itpub.

阅读(1906) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册