基于流量指标的对数据库硬件资源分析方法与流程

本发明涉及一种对数据库硬件资源分析方法，尤其是一种基于流量指标的对数据库硬件资源分析方法。二、
背景技术：
：对于专控系统，为了保证业务正常运行，需要保证专控系统中的硬件资源的配置，从而保证专控系统的运行的可靠性能。基于申请人于2018年7月15日的技术交底书和
背景技术：
中现有的技术问题、技术特征和技术效果，做出本发明的申请技术方案。三、技术实现要素：本发明的客体是一种基于流量指标的对数据库硬件资源分析方法。为了克服上述技术缺点，本发明的目的是提供一种基于流量指标的对数据库硬件资源分析方法，因此保证专控系统的运行的可靠性能。为达到上述目的，本发明采取的技术方案是：其步骤是：根据专控系统的复杂度系数，求得，需要配置的数据库硬件的tpmc值等于专控系统的复杂度系数与期望需要的tpmc值乘积。由于设计了专控系统的复杂度系数，得到了专控系统的一个标准计算值，按照标准计算值进行专控系统的硬件资源匹配，因此保证专控系统的运行的可靠性能。本发明设计了，按照专控系统的复杂度系数为基数匹配数据库硬件资源。本发明设计了，其步骤是：在专控系统中建立tpc-c基准业务模型，通过压力测试对比标准业务，由tpc-c基准业务模型，得到最大tpmc值，通过实际业务，由tpc-c基准业务模型，得到实际业务的tpmc值，专控系统的复杂度系数等于最大tpmc值与实际业务的tpmc值的比值。本发明设计了，tpc-c基准业务模型需要处理的交易事务主要为以下几种：一、新订单(new-order)：客户输入一笔新的订货交易，二、支付操作(payment)：更新客户帐户余额以反映其支付状况，三、发货(delivery)：发货(模拟批处理交易)，四、订单状态查询(order-status)：查询客户最近交易的状态，五、库存状态查询(stock-level)：查询仓库库存状况，以便能够及时补货。本发明设计了，tpc-c基准业务模型的warehouse模块分别设置为与district模块和stock模块关联，item模块设置为与stock模块关联，district模块设置为与customer模块关联，customer模块分别设置为与history模块和order模块关联，order分别模块设置为与new-order模块和order-line模块关联，stock模块关设置为与order-line模块关联。本发明设计了，根据实际业务的专卖业务系统的核心业务场景-稽查员日志填写的查询稽查计划、填写稽查日志(头行表)、返回稽查日志列表，四个sql抽取出来，形成一组数据库业务。本发明设计了，测试方法：一、tpcc测试tpc-c测试内容：数据库事务处理测试，衡量服务器及数据库软件处理在线查询交易处理(oltp)的性能表现。正规tpc-c测试结果发布必须提供tpmc值，即每分钟完成多少笔tpc-c数据库交易(tpc-ctransactionperminute)。二、测试工具测试过程采用benchmarksql-4.1.1工具进行测试，采用标准的事务组合以及权重值，如下：三、测试环境测试过程测试了两种情况，一种情况是压测单个数据库最大的tpmc值，另一种情况是压测服务器在多个数据库情况下，服务器的tpmc值最大上限测试。测试都是采用初始化100个仓库的情况，./runloader.shprops.db2numwarehouses100配置文件：本发明设计了，选取专控系统中三台服务器a、服务器b和服务器c,通过压力测试，得到服务器a的最大tpmc值为553617.49、服务器b的最大tpmc值为382983.53、服务器c的最大tpmc值为779081，根据实际业务的专卖业务系统的核心业务场景-稽查员日志填写的查询稽查计划、填写稽查日志(头行表)、返回稽查日志列表，四个sql抽取出来，形成一组数据库业务，(如何转换成tpc-c基准业务模型中的新订单(new-order)、支付操作(payment)、发货(delivery)、订单状态查询(order-status)、库存状态查询(stock-level))，由tpc-c基准业务模型，得到服务器a的实际业务的tpmc值为134209.8、服务器b的实际业务的tpmc值为92092.7、服务器c的实际业务的tpmc值为200847.8，通过计算得到，专控系统的服务器a的复杂度系数为4.12，专控系统的服务器b的复杂度系数为4.15，专控系统的服务器c的复杂度系数为3.88，通过进行复杂度系数平均值计算得到，专控系统的复杂度系数为4，当期望需要的tpmc为10000时，需要配置的数据库硬件的tpmc值为40000。本发明设计了，先在测试服务器上用基准模型做压力测试，在cpu满负荷情况下(因为对于服务器来讲cpu的扩展性相对来说比较低，而磁盘和内存的可扩展性较高，当磁盘和内存先出瓶颈时可考虑扩展磁盘和内存)，从而得出基准tpmc值，假设m；然后再将要部署的系统中核心业务场景sql提取出来形成数据库业务，再用相同服务器进行压力测试，从而得出业务tpmc值，假设为n。算出m/n的系数，即实际业务相对于基准业务的复杂度，假设为x。根据实际业务需要的某一时间点最大并发量，假设为y,只有当所购买的服务器的tpmc值满足xy时,此服务器才能满足我们部署的需求。因此，在购置服务器之前，可让供应商用我们的基准模型对服务器进行压力测试，得出的基准tpmc值刚好或略大于xy时，即可认为是适合我们购置的服务器。在本技术方案中，硬件资源是指cpu内存和磁盘。在本技术方案中，专控系统的复杂度系数为基数为重要技术特征，在基于流量指标的对数据库硬件资源分析方法的
技术领域：
中，具有新颖性、创造性和实用性，在本技术方案中的术语都是可以用本
技术领域：
中的专利文献进行解释和理解。四、附图说明为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1为本发明的tpc-c基准业务模型的交易事务的关系和大小示意图，图2为本发明的第一个实施例之一的数据库cpu监控数据图，图3为本发明的第一个实施例之一的内存使用情况图，图4为本发明的第一个实施例之一的网络使用情况图，图5为本发明的第一个实施例之一的磁盘监控数据图，图6为本发明的第一个实施例之一的压测过程中进程队列情况图，图7为本发明的第一个实施例之二的数据库cpu监控数据图，图8为本发明的第一个实施例之二的内存使用情况图，图9为本发明的第一个实施例之二的网络使用情况图，图10为本发明的第一个实施例之二的磁盘监控数据图，图11为本发明的第一个实施例之二的压测过程中进程队列情况图，图12为本发明的第一个实施例之三的数据库cpu监控数据图，图13为本发明的第一个实施例之三的内存使用情况图，图14为本发明的第一个实施例之三的网络使用情况图，图15为本发明的第一个实施例之三的磁盘监控数据图，图16为本发明的第一个实施例之三的压测过程中进程队列情况图。五、具体实施方式根据审查指南，对本发明所使用的诸如“具有”、“包含”以及“包括”术语应当理解为不配出一个或多个其它元件或其组合的存在或添加。在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。此外，下面所描述的本发明不同实施方式中所涉及的技术特征只要彼此之间未构成冲突就可以相互结合。下面结合实施例，对本发明进一步描述，以下实施例旨在说明本发明而不是对本发明的进一步限定。本发明的第一个实施例之一，其步骤是：在专控系统中建立tpc-c基准业务模型，通过压力测试对比标准业务，由tpc-c基准业务模型，得到最大tpmc值，通过实际业务，由tpc-c基准业务模型，得到实际业务的tpmc值，专控系统的复杂度系数等于最大tpmc值与实际业务的tpmc值的比值，根据专控系统的复杂度系数，需要配置的数据库硬件的tpmc值等于专控系统的复杂度系数与期望需要的tpmc值乘积。在本实施例中，tpc-c基准业务模型是针对数据库服务器性能的一个测试标准，这个标准描述了一个业务系统场景(以下称为标准业务)，即一个大型的商品批发销售公司，它拥有若干个分布在不同区域的商品仓库。当业务扩展的时候，公司将添加新的仓库，每个仓库负责为10个销售点供货，其中每个销售点为3000个客户提供服务，每个客户提交的订单中，平均每个订单有10项产品，所有订单中约1％的产品在其直接所属的仓库中没有存货，必须由其他区域的仓库来供货。同时，每个仓库都要维护公司销售的100000种商品的库存记录。在本实施例中，tpc-c基准业务模型需要处理的交易事务主要为以下几种：一、新订单(new-order)：客户输入一笔新的订货交易，二、支付操作(payment)：更新客户帐户余额以反映其支付状况，三、发货(delivery)：发货(模拟批处理交易)，四、订单状态查询(order-status)：查询客户最近交易的状态，五、库存状态查询(stock-level)：查询仓库库存状况，以便能够及时补货，tpc-c基准业务模型的交易事务的关系和大小如附图1中，warehouse模块分别设置为与district模块和stock模块关联，item模块设置为与stock模块关联，district模块设置为与customer模块关联，customer模块分别设置为与history模块和order模块关联，order分别模块设置为与new-order模块和order-line模块关联，stock模块关设置为与order-line模块关联，其中，表框里的数字表示该表将要存放多少条记录，仓库数w的调整在测试中能够体现数据库所能够支持的数据规模的能力；表间的数据表示数据的父子关系之间儿子的个数，比如一个warehouse要对应10个district等，另外，“+”号表示这种对应关系可能会更多。在本实施例中，流量指标(简称tpmc)：按照国际标准的定义，就是描述了系统在执行支付操作、订单状态查询、发货和库存状态查询这4种交易的同时，每分钟可以处理多少个新订单交易。所有交易的响应时间必须满足tpc-c测试规范的要求，且各种交易数量所占的比例也应该满足tpc-c测试规范的要求。在这种情况下，流量指标值越大说明系统的联机事务处理能力越高，也就是数据库服务器所能承受的压力越大，比如说某数据库服务器以这个标准业务模型做测试，最终tpmc＝1000，说明这个数据库服务器每分钟所能承受的最大数据吞吐量为1000。在本实施例中，测试方法：一、tpcc测试tpc-c测试内容：数据库事务处理测试，衡量服务器及数据库软件处理在线查询交易处理(oltp)的性能表现。正规tpc-c测试结果发布必须提供tpmc值，即每分钟完成多少笔tpc-c数据库交易(tpc-ctransactionperminute)。二、测试工具测试过程采用benchmarksql-4.1.1工具进行测试，采用标准的事务组合以及权重值，如下：三、测试环境测试过程测试了两种情况，一种情况是压测单个数据库最大的tpmc值，另一种情况是压测服务器在多个数据库情况下，服务器的tpmc值最大上限测试。测试都是采用初始化100个仓库的情况，./runloader.shprops.db2numwarehouses100配置文件：四、测试结果测试数据库服务器所能达到的最大tpmc值，为了达到最大上限，本次测试案例中开启6个压测进程，压测过程持续运行10分钟，最终结果，总事务数5541927，总tpmc值553617.49，并明显看到磁盘io瓶颈，具体数据表格如下：五、测试用例业务测试选取专卖内管系统的核心业务场景-稽查员日志填写，每个稽查员填写日志需要三步操作:1、查询稽查计划，2、填写稽查日志(头行表)，3、返回稽查日志列表，将三步操作共计四个sql抽取出来，形成一组数据库业务，通过压力测试工具并发执行四个sql，测试用例认证及主要功能步骤描述如下：(1)、查询稽查员稽查计划(2)、新增稽查日志(涉及到头表和行表两个表)并保存。(3)、保存完成后返回稽查日志列表。测试过程本次测试进行了450并发下的详细测试，在测试过程中，详细记录并发压力下事务的tps和响应时间。压测过程中，设置固定时间点，尽可能450个线程同时操作，期间没有设置停顿时间。测试结果本次性能测试主要测试450并发下数据库的处理能力，记录事务的响应时间及tps。测试发现，系统在450及以下并发时，系统处理能力较为稳定，cpu和磁盘使用率达到80％左右，基本可以认为达到系统处理能力的峰值。·事务tps、响应时间：测试结果验证：检查数据库日志，对比事务数发现，事务通过率为100％。本发明的第一个实施例之二，测试方法：一、tpcc测试tpc-c测试内容：数据库事务处理测试，衡量服务器及数据库软件处理在线查询交易处理(oltp)的性能表现。正规tpc-c测试结果发布必须提供tpmc值，即每分钟完成多少笔tpc-c数据库交易(tpc-ctransactionperminute)。二、测试工具测试过程采用benchmarksql-4.1.1工具进行测试，采用标准的事务组合以及权重值，如下：三、测试环境测试过程测试了两种情况，一种情况是压测单个数据库最大的tpmc值，另一种情况是压测服务器在多个数据库情况下，服务器的tpmc值最大上限测试。测试都是采用初始化100个仓库的情况，./runloader.shprops.db2numwarehouses100配置文件：四、测试结果测试二采用测试相同测试数据设置，为了达到最大上限，本次测试案例中开启3个压测进程，压测过程持续运行10分钟，最终结果，总事务数1512266，总tpmc值151050.26，并明显看到磁盘io瓶颈，具体数据表格如下：五、测试用例业务测试选取专卖内管系统的核心业务场景-稽查员日志填写，每个稽查员填写日志需要三步操作:1、查询稽查计划，2、填写稽查日志(头行表)，3、返回稽查日志列表，将三步操作共计四个sql抽取出来，形成一组数据库业务，通过压力测试工具并发执行四个sql，测试用例认证及主要功能步骤描述如下：(1)、查询稽查员稽查计划(2)、新增稽查日志(涉及到头表和行表两个表)并保存。(3)、保存完成后返回稽查日志列表。测试过程本次测试进行了450并发下的详细测试，在测试过程中，详细记录并发压力下事务的tps和响应时间。压测过程中，设置固定时间点，尽可能450个线程同时操作，期间没有设置停顿时间。测试结果本次性能测试主要测试450并发下数据库的处理能力，记录事务的响应时间及tps。测试发现，系统在450及以下并发时，系统处理速度较高，cpu使用率较低，但是磁盘使用达到峰值达到90％-100％左右，基本可以认为达到系统处理能力的峰值。·事务tps、响应时间：线程总事务数开始时间结束时间总时长(s)tpmc线程130000015:44:0115:53:46585.730732.5线程230000015:44:0115:53:47586.730680.1线程330000015:44:0115:53:47586.730680.1合计90000092092.7测试结果验证：检查数据库日志，对比事务数发现，事务通过率为100％。本发明的第一个实施例之三，测试方法：一、tpcc测试tpc-c测试内容：数据库事务处理测试，衡量服务器及数据库软件处理在线查询交易处理(oltp)的性能表现。正规tpc-c测试结果发布必须提供tpmc值，即每分钟完成多少笔tpc-c数据库交易(tpc-ctransactionperminute)。二、测试工具测试过程采用benchmarksql-4.1.1工具进行测试，采用标准的事务组合以及权重值，如下：三、测试环境测试过程测试了两种情况，一种情况是压测单个数据库最大的tpmc值，另一种情况是压测服务器在多个数据库情况下，服务器的tpmc值最大上限测试。测试都是采用初始化100个仓库的情况，./runloader.shprops.db2numwarehouses100配置文件：四、测试结果采用相同测试数据设置，为了达到最大上限，本次测试案例中开启3个压测进程，压测过程持续运行10分钟，最终结果，总事务数7793892，总tpmc值779081，并明显资源使用上瓶颈，具体数据表格如下：进程总事务数开始时间结束时间tpmctpcc25981532016-07-2722:56:272016-07-2723:06:31259805.98tpcc125323192016-07-2722:56:202016-07-2723:06:23252943.38tpcc226634202016-07-2722:56:152016-07-2723:06:15266331.64合计7793892779081五、测试用例业务测试选取专卖内管系统的核心业务场景-稽查员日志填写，每个稽查员填写日志需要三步操作:1、查询稽查计划，2、填写稽查日志(头行表)，3、返回稽查日志列表，将三步操作共计四个sql抽取出来，形成一组数据库业务，通过压力测试工具并发执行四个sql，测试用例认证及主要功能步骤描述如下：(1)、查询稽查员稽查计划(2)、新增稽查日志(涉及到头表和行表两个表)并保存。(3)、保存完成后返回稽查日志列表。测试过程本次测试进行了450并发下的详细测试，在测试过程中，详细记录并发压力下事务的tps和响应时间。压测过程中，设置固定时间点，尽可能450个线程同时操作，期间没有设置停顿时间。测试结果本次性能测试主要测试450并发下数据库的处理能力，记录事务的响应时间及tps。测试发现，系统在450及以下并发时，系统处理速度较高，cpu使用率较低，但是磁盘使用达到峰值达到90％-100％左右，基本可以认为达到系统处理能力的峰值。·事务tps、响应时间：线程总事务数开始时间结束时间总时长(s)tpmc线程130000023:11:3523:16:03268.866960.5线程230000023:11:3623:16:03268.667001.9线程330000023:11:3523:16:03269.166885.4合计900000200847.8测试结果验证：检查数据库日志，对比事务数发现，事务通过率为100％。本发明的第二个实施例，选取专控系统中三台服务器a、服务器b和服务器c,通过压力测试，得到服务器a的最大tpmc值为553617.49、服务器b的最大tpmc值为382983.53、服务器c的最大tpmc值为779081，根据实际业务的专卖业务系统的核心业务场景-稽查员日志填写的查询稽查计划、填写稽查日志(头行表)、返回稽查日志列表，四个sql抽取出来，形成一组数据库业务，(如何转换成tpc-c基准业务模型中的新订单(new-order)、支付操作(payment)、发货(delivery)、订单状态查询(order-status)、库存状态查询(stock-level))，由tpc-c基准业务模型，得到服务器a的实际业务的tpmc值为134209.8、服务器b的实际业务的tpmc值为92092.7、服务器c的实际业务的tpmc值为200847.8，通过计算得到，专控系统的服务器a的复杂度系数为4.12，专控系统的服务器b的复杂度系数为4.15，专控系统的服务器c的复杂度系数为3.88，通过进行复杂度系数平均值计算得到，专控系统的复杂度系数为4，当期望需要的tpmc为10000时，需要配置的数据库硬件的tpmc值为40000。在本实施例中，先在测试服务器上用基准模型做压力测试，在cpu满负荷情况下(因为对于服务器来讲cpu的扩展性相对来说比较低，而磁盘和内存的可扩展性较高，当磁盘和内存先出瓶颈时可考虑扩展磁盘和内存)，从而得出基准tpmc值，假设m；然后再将要部署的系统中核心业务场景sql提取出来形成数据库业务，再用相同服务器进行压力测试，从而得出业务tpmc值，假设为n。算出m/n的系数，即实际业务相对于基准业务的复杂度，假设为x。根据实际业务需要的某一时间点最大并发量，假设为y,只有当所购买的服务器的tpmc值满足xy时,此服务器才能满足我们部署的需求。因此，在购置服务器之前，可让供应商用我们的基准模型对服务器进行压力测试，得出的基准tpmc值刚好或略大于xy时，即可认为是适合我们购置的服务器。本发明具有下特点：1、由于设计了专控系统的复杂度系数，得到了专控系统的一个标准计算值，按照标准计算值进行专控系统的硬件资源匹配，因此保证专控系统的运行的可靠性能。2、由于设计了专控系统的复杂度系数，保证了专控系统的硬件资源之间的匹配性能，提高了专控系统的运算速度。3、由于设计了对结构形状进行了数值范围的限定，使数值范围为本发明的技术方案中的技术特征，不是通过公式计算或通过有限次试验得出的技术特征，试验表明该数值范围的技术特征取得了很好的技术效果。4、由于设计了本发明的技术特征，在技术特征的单独和相互之间的集合的作用，通过试验表明，本发明的各项性能指标为现有的各项性能指标的至少为1.7倍，通过评估具有很好的市场价值。还有其它的与专控系统的复杂度系数为基数相同或相近似的技术特征都是本发明的实施例之一，并且以上所述实施例的各技术特征可以进行任意的组合，为满足专利法、专利实施细则和审查指南的要求，不再对上述实施例中的各个技术特征所有可能的组合的实施例都进行描述。上述实施例只是本发明所提供的基于流量指标的对数据库硬件资源分析方法的一种实现形式，根据本发明所提供的方案的其他变形，增加或者减少其中的成份或步骤，或者将本发明用于其他的与本发明接近的
技术领域：
，均属于本发明的保护范围。当前第1页12