如何规划和选择数据库服务器...

 

如何规划和选择数据库服务器

当一个新的业务系统开发完成后，需要在一个区域乃至全国推广此应用软件，如何根据业务规模来选择服务器配置、内外置磁盘大小、以及网络带宽，是一件复杂的事情。

　　一个最真实的评估，是建立一个接近真实业务应用的操作环境，进行各种压力测试，测算出不同的用户数量下，系统的响应时间和吞吐量，并得出当时服务器的各种资源的利用率情况，对硬件资源的完整评估，需要考虑下列三个方面:

　　服务器性能的评估

　　客户端工作站或前端桌面的评估

　　通讯网卡和网络带宽的评估

　　如果不能建立准确的压力测试环境，需要根据工业界的Benchmark对服务器进行评估，推算出符合业务规模的服务器配置,同时要考虑在做系统管理时所消耗的资源，如在做备份、恢复、问题诊断、性能分析时、软件维护时都会对资源带来附加的消耗，对重要资源要考虑为将来留下升级和可扩展的余地，下列是一些通用的原则:

　　处理器:要考虑高峰时的处理器的能力，并适当保留一些缓冲，确保在业务增长时，系统有扩展的余地。如果要保持快速的响应能力，应当为CPU保留20%至40%的富余量。

　　内存:要为运行在此服务器的所有应用软件考虑内存，所需要的内存主要依赖于用户数、应用程序类型、进程的方式、和应用程序处理的数据量决定。

　　磁盘:评估业务的实际用户的数据量，以此推算出磁盘的最小个数，不要忘记选择备份设备(如磁带机)。

　　IO槽:尽量保留更多的IO槽，防止将来插更多的PCI卡。

　　网络:选择合适的网卡，保证网络不是系统的瓶颈。

　　在评估数据库服务器性能时，最困难的事情是如何把握准确度问题，到底考虑哪些因素等。理想情况下，应考虑下列要素:

　　交易的复杂性

　　交易率

　　数据读/写比例

　　并发连接数目

　　并发交易数目

　　数据库最大表的大小

　　性能度量的目标

　　根据各种Benchmark测试结果和对各种生产系统的检测，下表概括了CPU、磁盘、内存页面、网络和虚存页交换的利用率，可看出一个服务器如果其利用率保持在Good 所标示的范围内时，是一种理想的模式。

基于rPerf的推算，评估数据库服务器的CPU

　　rPerf(Relative performance)是从IBM公司解析模型得出的商务处理性能估计值。该模型模拟部分系统的操作，如中央处理器、高速缓存和内存，该模型没有模拟磁盘和网络的输入/输出操作。虽然采用了一般数据库和操作系统的参数，但该模型不能反映出具体的数据库或AIX版本。除非单独说明，否则rPerf均在系统推出时估计。IBM pSeries 640-B80为基准参照系统，其值为本。虽然rPerf可用于比较商业处理性能，但实际的系统性能可能不同，取决于许多因素，包括系统硬件配置和软件设计与配置。

　　评估数据库服务器的性能，需要理解交易的类型、高峰期的情况、用户数量、在高峰时每个用户的交易数量。假如在高峰时，有三种典型的交易类型:轻的、一般的、重的。需要知道高峰时，每种交易的并发用户数目。假定高峰时间为:10:00-11:00，每个用户的交易数目如下:

　　轻的交易 =120 交易/用户

　　一般的交易= 60 交易/用户

　　重的交易 = 15交易/用户

　　每个交易所使用的CPU秒

　　评估出交易类型后，需要评估出运行每个交易所消耗的CPU秒，如果假定B80服务器每秒中支持10个交易，则每个交易需要消耗0.1个CPU秒。如果不知道如何评定CPU秒，则根据应用类型参照下列表。

　　基于rPerf的推算，评估数据库服务器的CPU

　　rPerf(Relative performance)是从IBM公司解析模型得出的商务处理性能估计值。该模型模拟部分系统的操作，如中央处理器、高速缓存和内存，该模型没有模拟磁盘和网络的输入/输出操作。虽然采用了一般数据库和操作系统的参数，但该模型不能反映出具体的数据库或AIX版本。除非单独说明，否则rPerf均在系统推出时估计。IBM pSeries 640-B80为基准参照系统，其值为本。虽然rPerf可用于比较商业处理性能，但实际的系统性能可能不同，取决于许多因素，包括系统硬件配置和软件设计与配置。

　　评估数据库服务器的性能，需要理解交易的类型、高峰期的情况、用户数量、在高峰时每个用户的交易数量。假如在高峰时，有三种典型的交易类型:轻的、一般的、重的。需要知道高峰时，每种交易的并发用户数目。假定高峰时间为:10:00-11:00，每个用户的交易数目如下:

　　轻的交易 =120 交易/用户

　　一般的交易= 60 交易/用户

　　重的交易 = 15交易/用户

　　下面举例说明如何计算所需的rPerf值，假定某公司的情况如下:

　　业务高峰时间: 10:00-11:00=1Hour=3600秒

　　交易类型: 无复杂查询的简单应用

　　相对交易类型，用户数目分布:轻的=2000, 一般=50, 重的=5

　　在高峰时，每个用户的交易数量:

　　轻的=120交易/用户

　　一般=60交易/用户

　　重的=15交易/用户

　　对于rPerf=1的服务器，每个交易响应的CPU秒

　　轻的=1

　　一般=3

　　重的=15

　　最大的CPU利用率:60%

　　根据上述公式，可推算出不同交易类型所对应的rPerf值。

　　轻的交易:NU*TX*CS/PP=2000*120*1/3600=66.0

　　一般交易:NU*TX*CS/PP=50*60*3/3600=2.5

　　重的交易:NU*TX*CS/PP=5*15*15/3600=0.3

　　所需的总的rPerf/MC=(66.0+2.5+0.3)/0.7=98.3 rPerf

基于TPC-C的推算，评估数据库服务器的CPU

　　TPC-C基准是事务处理委员会建立的一个专门演示在线事务处理性能(OLTP)的性能基准，它的测量方法是为了使客户能够评估不同的在线事务处理系统的性能，这些事务进程于一个可控制的状态下在一个标准的数据库中运行。

　　TPC-C测试包括5个典型的OLTP事务，它们是:

　　新订单　:一个用户提交一个新的订单

　　支付　　:更新用户的账户余额以反映一个支付

　　交付　　:订单的交付(通过一个批事务处理实现)

　　订单状态:返回用户最新订单的状态

　　库存水平:监控当前仓库库存

　　TPC-C的事务处理是在一个9个表的数据库上实现的事务处理过程包括:更新、插入、删除、终止，以及对主和次级键的访问,每种事务处理90%的响应时间应小于或等于5秒，其中，库存水平的响应时间可以在20秒以内。

　　TPC-C的吞吐量值是终端活动水平的直接结果，如每一个仓库有10个终端，在每一个终端上上述5个事务都是可用的，一个远程的终端仿真器被用来在性能测试过程中进行必要的事务混合工作。这个混合代表着一个完整的订单商务处理流程:录入、支付、检验、交付。更专业的是，这个必要的混合被定义为产生一个相等数量的新订单和支付事务，以及在每10个新订单事务中产生一个交付事务，一个订单状态检验事务和一个库存水平检验事务

　　远程终端仿真器也被用来测量每一个事务的响应时间，以及用来模拟键入时间及思考时间，键入时间是指在终端上录入数据所花费的时间，思考时间是指操作人员在终端读取事务的结果，进行下一个事务请求之前所花费的时间。每一个事物都有一个最小键入时间和最小思考时间。另外，这个响应时间必须在一个给定的极限值之下。

　　TPC-C基准测试的结果--TPC-C的吞吐量(tpmC)，代表的是系统的最大的持续性能，它被定义为系统每分钟可以处理多少个新订单事务，与此同时，系统还在处理其他四种事务类型(支付、订单状态、交付、库存水平)。所有5个TPC-C事务都有某个限定的用户响应时间要求，其中新订单事务的响应时间是5秒以内。因此如果一个系统的TPC-C值是100tpmC/min，说明该系统在每分钟处理其他的混合的TPC-C事务的工作的同时，可以产生100个新订单事务。

　　如何使用TPC-C进行服务器的评估

　　由上可知，TPC-C测试基准主要用于测试主机服务器每分钟能够处理的联机交易笔数，测试产生的单位结果是TPM值(Transaction Per Minute，即每分钟处理的交易比数)。

　　TPC-C虽然客观的反映了各个计算机厂商的系统处理性能，并且测试基准也在不断完善以更加贴近现实应用的交易环境，但是仍然无法与纷繁多样的各类实际应用完全吻合;而且参加TPC测试的主机系统都做了适当程度的系统优化。因此，在实际业务应用系统选择主机服务器乘载体时，必须考虑到多方面的因素，以最大程度的做到适合应用系统的生产需求。

　　以下计算公式是IBM公司在金融综合业务系统的实际应用中总结的经验方法论，基本反映了金融业务特点对主机处理能力的需求:

　　TPM=TASK x 80% x S x F / (T x C)

　　其中:

　　TASK:为每日业务统计峰值交易量

　　T:为每日峰值交易时间，假设每日80%交易量集中在每天的4小时，即240分钟内完成:T=240。

　　S:为实际银行业务交易操作相对于标准TPC-C测试基准环境交易的复杂程度比例。由于实际的金融业务交易的复杂程度与TPC?C标准测试中的交易存在较大的差异，须设定一个合理的对应值。以普通储蓄业务交易为例，一笔交易往往需要同时打开大量数据库表，取出其相关数据进行操作，相对于TPC-C标准交易的复杂度，要复杂很多;根据科学的统计结果，每笔交易操作相比较于TPC标准测试中的每笔交易的复杂度此值可设定为10~20。

　　C:为主机CPU处理余量。实际应用经验表明，一台主机服务器的CPU利用率高于80%则表明CPU的利用率过高会产生系统瓶颈，而利用率处于75%时，是处于利用率最佳状态。因此，在推算主机性能指标时，必须考虑CPU的冗余，设定C=75%。

　　F:为系统未来3~5年的业务量发展冗余预留。

　　综上所述，为保障联机业务处理性能要求，我们可推算得出主机所需的处理能力，据此得出相应的机型和配置。

举例说明，使用TPC-C进行数据库服务器评估

　　下面针对XYZ行的网上银行业务的需求，我们进行数据库服务器的选型分析。

　　由于目前XYZ行只有17个分行开通了网上银行业务，据我们估计，按照目前的客户数量，全部分行都开通网上银行业务后，总的客户数量可以达到10万。考虑INTERNET在我国的迅猛发展，客户数量的年增长率按照50%计算，那么，3年后的客户数量将达到10万×(1+50%)3≈34万。

　　这些客户当中，至少有一半是个人客户，另一半是企业客户。企业客户的交易频率比较高，我们按平均每个企业客户每天做1.5笔交易计算;个人客户常用的交易是查询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4次交易;那么，每天的交易量就是:

　　34万×50%×1.5+34万×50%×(4÷30) ≈28万笔

　　假设网上银行的交易复杂度达到15，那么，每天的数据库操作数达到:

　　28万×15=420万次

　　高法诉讼费缴费:

　　由于诉讼费的增长量不大，我们按年递增率5%计算。根据XYZ总行的统计，全国共37家分行，缴费量比较大的分行可以达到25000笔每月，占分行总数的20%;缴费量中等的省可达到15000笔每月，占分行总数的30%;缴费量小的省可达到7000笔每月，占分行总数的50%;按一个月20个工作日计算。这样，三年后每天的交易数量可以达到:

　　(25000×20%+15000×30%+7000×50%)×37÷20×(1+5%)3≈28740笔

　　我们假设高法诉讼缴费的交易复杂度达到13，那么每天的数据库操作达到:

　　28740*13=373620次

　　整体性能要求:

　　总的数据库操作次数是:4200000+373620=4573620

　　假设每天的交易的80%集中在4小时内发生，那么高峰交易时间内每分钟的数据库联机交易次数为:4573620×80%÷(4×60)≈15250

　　要为将来陆续加入的应用预留40%的处理能力;另外，考虑到CPU的繁忙时间低于70%时，系统的性能较好，我们把这个比例定在65%。所以系统的TPC-C值应达到:15250÷(1-40%)÷65%≈39000

　　内存容量需求分析

　　首先根据数据库容量算出所需的数据库缓存大小，再估计出操作系统、系统软件等所需内存，合计即是所需的内存容量。

　　网银数据量分析:

　　XYZ总行网上银行系统的数据库由CIF信息，交易日志、交易流水三部分组成。

　　其中:CIF信息包括企业客户和个人客户信息，企业客户信息平均大小为20K左右，个人客户信息平均大小为5K左右;每一笔交易都要记交易日志，日志的平均大小为4K左右;每一笔转帐交易都要记交易流水，交易流水的大小为2K左右。

　　这些客户当中，至少有一半是个人客户，另一半是企业客户。企业客户的交易频率比较高，我们按平均每个企业客户每天做1.5笔交易计算;个人客户常用的交易是查询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4次交易;那么，每天的交易量就是:

　　所有的交易日志和交易流水都要保留三个月。由于个人客户的转帐交易非常少，可以忽略不计;假定企业客户的转帐交易占总交易量的70%。我们就可以计算网上银行对存储系统容量的要求:

　　CIF信息容量=20K×(34万×50%)+5K×(34万×50%)=3.25GB+421MB ≈ 4GB

　　交易日志容量=[34万×50%×1.5+34万×50%×(4÷30)] ×4K×30×3 =277667×4K×30×3 ≈95GB

　　交易流水容量=(34万×50%×1.5)×70%×2K×30×3 ≈30GB

　　XYZ网上银行总体数据容量要求:=4GB+95GB+30GB=129GB

　　高法诉讼费数据量分析:

　　高法的交易数据按要求要保留三年，每笔交易记录的大小为512字节，总体容量为:(25000×20%+15000×30%+7000×50%)×37×12×3×0.5K≈8.2GB

　　因此，数据库的总数据量为: 129GB+8.2GB=137.2GB

　　数据库系统在缓存容量达到数据库总容量的5%时性能较好，因此，数据库缓存大小为:6.86GB。

　　从而计算出系统内存需求为:

　　1. AIX操作系统所占的内存 128MB

　　2. 数据库管理系统所占的内存 256MB

　　3. 双机热备等系统软件所占的内存 128MB

　　4. 应用程序所占的内存 256MB

　　5. 数据库缓存 6.86GB

　　6. 合理的内存利用率 75%

　　总计 10GB

　　存储容量需求分析

　　除了上述的XYZ网上银行系统和高法诉讼费缴费系统的存储容量要求之外，还有异步查询下载服务的存储要求。

　　异步查询下载服务每隔1小时生成一个下载数据包，每个数据包的大小为3MB，需要下载的数据包是上午十点生成的数据包，这个数据包需要保存2年，其它数据包只要保存3个月。因此，存储容量为:

　　23×3M×30×3+1×3M×365*2=6GB+2GB=8GB

　　为避免存储系统成为系统性能的瓶颈，系统存储系统的使用率应小于40%，建议采用镜像方式存储数据，因此总的存储容量为:

　　(137.2GB+8GB)÷40% ×2= 766GB

很好啊