CN106156115A - 一种资源调度方法及装置 - Google Patents

Abstract

本发明公开了一种资源调度方法，包括：利用当前采集的性能指标，评估空闲资源；所述性能指标表征数据库资源的使用情况；根据所述空闲资源评估结果确定数据库的负载小于预设值时，利用预估的资源周期性消耗结果，进行空闲资源周期性预估；根据预估的周期性空闲资源及对应时长，从队列任务基线库的任务队列中匹配出待执行任务；所述任务队列中的任务为与数据库维护相关的任务；利用所述预估的周期性空闲资源执行匹配出的待执行任务。本发明同时还公开了一种资源调度装置。

Description

一种资源调度方法及装置

技术领域

本发明涉及数据库领域，尤其涉及一种资源调度方法及装置。

背景技术

信息技术已成为电信行业至关重要的一种生产力，海量信息的管理和运营需要强大的业务系统支撑。业务系统的稳定性会直接影响到客户的信任度和满意度，如何掌握数据库资源使用规律，合理有效地利用空闲时段，缓解业务高峰，是业务支撑部门其中一项十分重要的职责。

现有技术中，调度各模块任务的方法主要有如下两种：

1)通过业务系统的操作系统或数据库的定时任务实现。具体地，数据库管理员(DBA，DataBase Administrator)根据经验判断，某时段较为空闲，剩余资源可以执行某个任务，于是将该任务以指定时间执行的方式配置到定时任务中，由操作系统或数据库调度。

2)手工执行。具体地，DBA发现数据库目前较为空闲，于是手工启动任务并值守至其结束，在这种情况下，当有业务高峰，数据库压力较大时，需要手工杀死异常的任务进程，以确保业务处理进程能获得所需资源。

从上面的描述中可以看出，目前调度各模块任务的方式主要依靠人工来实现，这样就会出现资源调度不及时、以及调度出错的问题。

发明内容

为解决现有存在的技术问题，本发明实施例提供一种资源调度方法及装置。

本发明实施例提供了一种资源调度方法，包括：

利用当前采集的性能指标，评估空闲资源；所述性能指标表征数据库资源的使用情况；根据所述空闲资源评估结果确定数据库的负载小于预设值时，利用预估的资源周期性消耗结果，进行空闲资源周期性预估；

根据预估的周期性空闲资源及对应时长，从队列任务基线库的任务队列中匹配出待执行任务；所述任务队列中的任务为与数据库维护相关的任务；

利用所述预估的周期性空闲资源执行匹配出的待执行任务。

上述方案中，所述利用所述预估的周期性空闲资源执行匹配出的待执行任务时，所述方法还包括：

确定所述匹配出的待执行任务有断点时，利用所述预估的周期性空闲资源从断点处执行所述匹配出的待执行任务。

上述方案中，所述利用所述预估的周期性空闲资源执行匹配出的待执行任务的过程中，所述方法还包括：

根据利用下一次采集的性能指标得出的所述空闲资源评估结果确定数据库的负载大于等于所述预设值时，暂停任务的执行，释放相应的资源，并保存暂停执行的任务的中间状态。

上述方案中，所述利用当前采集的性能指标，评估空闲资源之前，所述方法还包括：

周期性采集并保存所述性能指标；

基于保存的所述性能指标，采用同比和/或环比的方式，得出资源消耗规律；

根据所述资源消耗规律，对所述资源周期性消耗进行预估。

上述方案中，所述根据预估的周期性空闲资源及对应时长，从任务队列中匹配出待执行任务，包括：

将所述任务队列中的待执行任务按照所述队列任务基线库中采集的顺序进行排序；

按照排序结果，并根据预估的周期性空闲资源及对应时长，从所述任务队列中依次匹配出所述待执行任务。

上述方案中，所述根据预估的周期性空闲资源及对应时长，从队列任务基线库的任务队列中匹配出待执行任务之前，所述方法还包括：

周期性从所述数据库中采集并保存结构化查询语言(SQL，Structured QueryLanguage)性能指标，并进行对应的业务绑定；

确定保存的SQL性能指标不存在对应基线时，在所述队列任务基线库或应用基线库中建立对应的基线；或者，

确定保存的SQL性能指标在所述队列任务基线库或应用基线库中存在对应基线时，采用同比的方式，确定SQL消耗增长指标中的频次及资源消耗指标的增长率；并校正所述对应基线的相关数据。

上述方案中，所述采用同比的方式，确定SQL消耗增长指标中的频次及资源消耗指标的增长率，为：

基于当日的频次及上月同日的频次，并结合保存的样本数，确定频次的增长率；并基于当日的资源消耗指标及上月同日的资源消耗指标，并结合保存的样本数，确定资源消耗指标的增长率。

本发明实施例还提供了一种资源调度装置，包括：第一评估单元、第二评估单元、任务匹配单元及任务执行单元；其中，

所述第一评估单元，用于利用当前采集的性能指标，评估空闲资源；所述性能指标表征数据库资源的使用情况；

所述第二评估单元，用于根据所述空闲资源评估结果确定数据库的负载小于预设值时，利用预估的资源周期性消耗结果，进行空闲资源周期性预估；

所述任务匹配单元，用于根据预估的周期性空闲资源及对应时长，从队列任务基线库的任务队列中匹配出待执行任务；所述任务队列中的任务为与数据库维护相关的任务；

所述任务执行单元，用于利用所述预估的周期性空闲资源执行匹配出的待执行任务。

上述方案中，所述任务执行单元，具体用于：确定所述匹配出的待执行任务有断点时，利用所述预估的周期性空闲资源从断点处执行所述匹配出的待执行任务。

上述方案中，所述任务执行单元，还用于在利用所述预估的周期性空闲资源执行匹配出的待执行任务的过程中，根据利用下一次采集的性能指标得出的所述空闲资源评估结果确定数据库的负载大于等于所述预设值时，暂停任务的执行，释放相应的资源，并保存暂停执行的任务的中间状态。

上述方案中，所述装置还包括：第三评估单元，用于周期性采集并保存所述性能指标；基于保存的所述性能指标，采用同比和/或环比的方式，得出资源消耗规律；并根据所述资源消耗规律，对所述资源周期性消耗进行预估。

上述方案中，所述装置还可以包括：基线库建立单元，用于周期性从所述数据库中采集并保存SQL性能指标，并进行对应的业务绑定；

确定保存的SQL性能指标不存在对应基线时，根据，在所述队列任务基线库或应用基线库中建立对应的基线；或者，

确定保存的SQL性能指标在所述队列任务基线库或应用基线库中存在对应基线时，采用同比的方式，确定SQL消耗增长指标中的频次及资源消耗指标的增长率；并校正所述对应基线的相关数据。

本发明实施例提供的资源调度方法及装置，利用当前采集的性能指标，评估空闲资源；所述性能指标表征数据库资源的使用情况；根据所述空闲资源评估结果确定数据库的负载小于预设值时，利用预估的资源周期性消耗结果，进行空闲资源周期性预估；根据预估的周期性空闲资源及对应时长，从队列任务基线库的任务队列中匹配出待执行任务；利用所述预估的周期性空闲资源执行匹配出的待执行任务，如此，能及时、有效、准确地进行资源调度。

附图说明

在附图(其不一定是按比例绘制的)中，相似的附图标记可在不同的视图中描述相似的部件。具有不同字母后缀的相似附图标记可表示相似部件的不同示例。附图以示例而非限制的方式大体示出了本文中所讨论的各个实施例。

图1为本发明实施例一资源调度方法流程示意图；

图2为本发明实施例二中进行数据库系统的资源周期性消耗预估，建立队列任务基线库及应用基线库并校正基线库中的对应基线的流程示意图；

图3为本发明实施例二中快照库示意图；

图4a为本发明实施例二中一天内系统CPU及IO使用曲线示意图；

图4b为本发明实施例二中16点时系统CPU及IO使用曲线示意图；

图5为本发明实施例二中进行资源动态分配的流程示意图；

图6a为本发明实施例二中动态调度优化前系统CPU及IO使用曲线示意图；

图6b为本发明实施例二中动态调度优化后系统CPU及IO使用曲线示意图；

图7a为本发明实施例二中业务模块数据库CPU资源占比示意图；

图7b为本发明实施例二中业务模块数据库IO资源占比示意图；

图8为本发明实施例三资源调度装置结构示意图。

具体实施方式

下面结合附图及具体实施例对本发明再作进一步详细地描述。

目前，调度各模块任务的方式主要依靠人工来实现，这样就会出现资源调度不及时、以及调度出错的问题，具体表现在以下几个方面：

1)通过操作系统或数据库的定时任务实现的方案依赖于DBA长期积累的维护经验，且无法预估和处理突发情况，比如在执行某个任务时，业务系统的业务突增，导致数据库资源争用；再比如：数据库业务骤减，当时却并没有配置定时的任务执行，导致数据库资源浪费。

2)手工执行的方案需要人工值守，依赖于DBA的技术水平及判断，被杀死的任务进程需要回滚，下次启动时无法从断点继续执行，这样容易造成数据状态不一致等问题。

3)现有的两种方案均无法获取业务模块及任务的资源消耗，很难感知程序逻辑导致的性能额外消耗问题。

4)现有的两种方案中，对于未来计划在数据库上执行的任务是否会超过该数据库的负载是无法精确评估的。

基于此，在本发明的各种实施例中：利用当前采集的性能指标，评估空闲资源；所述性能指标表征数据库资源的使用情况；根据所述空闲资源评估结果确定数据库的负载小于预设值时，利用预估的资源周期性消耗结果，进行空闲资源周期性预估；根据预估的周期性空闲资源及对应时长，从队列任务基线库的任务队列中匹配出待执行任务；利用所述预估的周期性空闲资源执行匹配出的待执行任务。

实施例一

本发明实施例资源调度方法，如图1所示，包括以下步骤：

步骤101：利用当前采集的性能指标，评估空闲资源；所述性能指标表征数据库资源的使用情况；根据所述空闲资源评估结果确定数据库的负载小于预设值时，利用预估的资源周期性消耗结果，进行空闲资源周期性预估；

这里，所述性能指标可以包括所述数据库的中央处理器(CPU，CentralProcessing Unit)及输入输出(I/O，Input/Output)使用情况指标；相应地，根据CPU指标及IO使用情况指标，进行空闲资源的评估。

当所述数据库的负载小于所述预设值时，说明所述数据库的负载较轻，这种情况下，可以根据需要执行任务队列中的待执行任务；当根据所述空闲资源评估结果确定数据库的负载大于等于预设值时，说明所述数据库负载过重，这种情况下，为了保证高优先级的业务(应用)的正常运行，如果有正在执行的任务队列中的任务时，需要暂停任务的执行，并释放相应的资源；此时，需要保存暂停执行的任务的中间状态，以保证后续执行该任务时可以从断点继续执行该任务。

其中，实际应用时，可以根据需要设置所述预设值。

在执行本步骤之前，该方法还可以包括：

周期性采集并保存所述性能指标；

基于保存的所述性能指标，采用同比和/或环比的方式，得出资源消耗规律；

根据所述资源消耗规律，对所述资源周期性消耗进行预估。

其中，根据所述预估的资源周期性消耗结果，可以估算出未来时间片里的空闲资源及对应的时长。

实际应用时，采集所述性能指标的周期可以根据需要确定，比如可以是一个月等。

实际应用时，可以定时采集所述数据库的性能数据，从这些性能数据中提取CPU及IO的使用情况指标，并建立系统快照，从而实现周期性采集并保存所述性能指标；

相应地，采用同比的方式，得出资源消耗规律具体可以是指：将每个月同一天，每天同一时刻的CPU及IO使用情况的快照相比对，得出系统消耗规律。采用环比的方式，是指：将每天各时段的CPU及IO使用情况的快照相比对，得出系统消耗规律。

步骤102：根据预估的周期性空闲资源及对应时长，从队列任务基线库的任务队列中匹配出待执行任务；

这里，所述任务队列中的任务是指：需要执行的任务。

所述根据预估的周期性空闲资源及对应时长，从任务队列中匹配出待执行任务，具体包括：

将所述任务队列中的待执行任务按照所述队列任务基线库中采集的顺序进行排序；

按照排序结果，并根据预估的周期性空闲资源及对应时长，从所述任务队列中依次匹配出所述待执行任务。

实际应用时，可以定时采集所述性能指标，相应地，每次定时采集的性能指标即为步骤101描述的当前采集的性能指标；这种情况下，当从任务队列中未匹配出待执行任务时，则依据规则进行下一次的定时采集性能指标。

实际应用时，所述匹配出的待执行任务的个数可以为一个以上。

在执行本步骤之前，该方法还可以包括：

周期性从所述数据库中采集并保存SQL性能指标，并进行对应的业务绑定；

确定保存的SQL性能指标在所述队列任务基线库或应用基线库中不存在对应基线时，在所述队列任务基线库或应用基线库中建立对应的基线；

确定保存的SQL性能指标在所述队列任务基线库或应用基线库中存在对应基线时，采用同比的方式，确定SQL消耗增长指标中的频次及资源消耗指标的增长率；并校正所述对应基线的相关数据。

其中，采集所述SQL性能指标的周期可以根据需要确定，比如可以是：一个小时等。

实际应用时，在采集并保存SQL性能指标时，可以定时从数据库的动态性能视图(V$SQL、V$SQL_PLAN等)中采集SQL性能数据，从这些SQL性能数据中提取SQL性能指标，并建立业务模块消耗快照，从而实现周期性从所述数据库中采集并保存SQL性能指标。其中，V$SQL可以反映存储的SQL语句；V$SQL_PLAN可以反映存储的SQL语句的执行计划。

所述SQL性能指标可以反映执行对应的SQL时，所消耗的时间、占用的资源情况，包括：相关的执行计划、表之间的链接情况等。所述SQL性能指标可以包括：SQL的频次及对应的资源消耗指标；其中，所述资源消耗指标可以包括：每次的CPU使用时间、每次的执行时间、每次的逻辑读、每次的物理读。其中，逻辑读是指从内存里访问数据，物理读是指从磁盘里访问数据。

相应地，采用同比的方式，确定SQL消耗增长指标中的频次及资源消耗指标的增长率是指：将每个月同一天的业务模块消耗快照相比对，从而确定出SQL消耗增长指标中的频次及资源消耗指标的增长率。

这里，在确定增长率时，基于当日的频次及上月同日的频次，并结合保存的样本数，确定频次的增长率；并基于当日的资源消耗指标及上月同日的资源消耗指标，并结合保存的样本数，确定资源消耗指标的增长率。

进行对应的业务绑定的目的是：形成对应基线，以便当基线库中不存在对应基线时，在所述队列任务基线库或应用基线库中建立对应的基线；或者，当基线库中存在对应基线时，确定增长率及校正基线库中对应基线的相关数据。

在进行对应的业务绑定时，当保存的SQL性能指标未在所述队列任务基线库或应用基线库中(即保存的SQL性能指标对应的基线未在所述队列任务基线库或应用基线库中)时，推送到未绑定业务标签列表中，由业务人员打上业务标签后，再回存到基线库，进行对应的业务绑定；对于保存的SQL性能指标已在所述队列任务基线库或应用基线库中的，则直接绑定业务标签，即进行对应的业务绑定，并建立业务模块消耗快照。

通过对比已存在的基线的相关数据，即可确定保存的SQL性能指标是否存在对应基线。

所述应用基线库的作用是存储多次在数据库中运行的相关任务信息，以便能从整体了解各任务占用的资源情况。

所述基线的作用可以理解为一个任务的基准线，如果这个基准线波动很大，则说明该任务异常，需要修改、调整等。

实际应用时，所述校正所述对应基线的相关数据的目的是：是为了减小对应任务的基准线，使得基准线波动尽可能的降低。

步骤103：利用所述预估的周期性空闲资源执行匹配出的待执行任务。

这里，在执行本步骤时，该方法还可以包括：

确定所述匹配出的待执行任务有断点时，利用所述预估的周期性空闲资源从断点处执行所述匹配出的待执行任务；

相应地，确定所述匹配出的待执行任务没有断点时，则直接启动匹配出的待执行任务。

其中，可以根据是否保存有暂停执行的任务的中间状态来确定对应待执行任务是否有断点。

在利用所述预估的周期性空闲资源执行匹配出的待执行任务的过程中，该方法还可以包括：

根据利用下一次采集的性能指标得出的所述空闲资源评估结果确定数据库的负载大于等于所述预设值时，暂停任务的执行，释放相应的资源，并保存暂停执行的任务的中间状态。

本实施例提供的资源调度方法，利用当前采集的性能指标，评估空闲资源；所述性能指标表征数据库资源的使用情况；根据所述空闲资源评估结果确定数据库的负载小于预设值时，利用预估的资源周期性消耗结果，进行空闲资源周期性预估；根据预估的周期性空闲资源及对应时长，从队列任务基线库的任务队列中匹配出待执行任务；利用所述预估的周期性空闲资源执行匹配出的待执行任务，如此，能及时、有效、准确地进行资源调度。

另外，确定所述匹配出的待执行任务有断点时，利用所述预估的周期性空闲资源从断点处执行所述匹配出的待执行任务，如此，能保证数据状态的一致性，进而节约了资源，提高资源的利用率。

实施例二

本实施例在实施例一的基础上，详细地描述资源调度方法。

首先，进行数据库系统的资源周期性消耗预估，建立队列任务基线库及应用基线库，并校正基线库中的对应基线。

具体地，进行数据库系统的资源周期性消耗预估时，如图2所示，应用本实施例方法的设备的采集层中配置有采集数据库系统性能数据的定时任务，以便采集层对数据库系统性能数据做定时采集；所述设备的分析层从所述采集层采集的性能数据中提取CPU及IO使用情况指标，建立系统快照，并将每个月同一天，每天同一时刻的CPU及IO的使用情况的快照相比对，得出系统消耗规律(采用同比和环比的方式，得出系统消耗规律)；所述设备的结果层根据所述系统消耗规律，对所述资源周期性消耗进行预估；在预估时，估算出未来时间片里，系统的空闲资源及对应时长。

建立队列任务基线库及应用基线库，并校正基线库中的对应基线时，如图2所示，所述采集层配置有采集数据库SQL性能数据的定时任务，以便所述采集层对数据库SQL性能数据(也可以称为SQL消耗)做定时采集；所述分析层从所述采集层采集的SQL性能数据中提取出SQL性能指标，对提取的SQL性能指标进行业务绑定，然后建立业务模块消耗快照；所述分析层再判断提取的SQL性能指标是否存在对应基线，如果存在，采用同比的方式，确定SQL消耗增长指标中的频次及资源消耗指标的增长率；并校正所述对应基线的相关数据；如果不存在对应基线，判断提取的SQL性能指标是否为队列任务，如果是，则在队列任务基线库中建立对应的基线；如果不是队列任务，则在应用基线库中建立对应的基线，也就是说，对于已存在基线的业务模块消耗，针对相关SQL进行增长率计算并修正基线，对于不存在基线的业务模块消耗，则创建相应的基线。

其中，所述分析层可以定时从数据库的动态性能视图(V$SQL、V$SQL_PLAN等)中采集SQL性能数据。

在进行对应的业务绑定时，当保存的SQL性能指标未在所述队列任务基线库或应用基线库中时，推送到未绑定业务标签列表中，由业务人员打上业务标签后，再回存到基线库，进行对应的业务绑定；对于保存的SQL性能指标已在所述队列任务基线库或应用基线库中的，则直接绑定业务标签，即进行对应的业务绑定。

从上面的描述中可以看出，本实施例需要建立专门的快照库，用于存放各业务模块的性能快照，如图3所示，快照库可以包含四大类指标：系统性能指标、SQL性能指标、SQL消耗增长指标、业务关联指标；其中，

SQL性能指标：从数据库中定时采集，主要从V$SQL、V$SQLAREA等动态性能视图里面获取、计算；

SQL消耗增长指标：通过计算各SQL性能指标快照中各指标的差值得到增长率，用于记录快照中SQL消耗的变化，主要用于校正基线中的相关数据的平均值；

系统性能指标：主要包括CPU中用户(USER)使用部分所占百分比、以及每秒系统读写了多少个数据块(即包括：CPU及IO使用情况指标)；这些指标可以从系统命令中获取；

业务关联指标：该指标需要业务人员手工填写。一般在所述设备上线后，批量初始化，对后期新增的SQL(如业务变更、新增业务等)则手工增量追加填写即可。这里，对于稳定的业务系统，一般后期需要追加填写的情况比较少见。建立业务关联指标快照的目的是：记录大版本变更、新业务增加后的系统情况等，以便能从整体了解各业务的情况。

利用连续的系统快照，采用环比和同比的方式，可以得出如图4a及图4b所示的趋势图，即得出系统消耗规律；根据图4a及图4b所示的趋势图，可以预估未来某时段资源使用情况及时长。

具体地，某时段CPU使用情况预估计算公式为：

fc＝(c1+c2+c3+....+cn)/n (1)

某时段IO使用情况预估计算公式为：

fp＝(p1+p2+p3+....+pn)/n (2)

其中，n为采集天数，cn为第N天该时段快照中CPU的使用率，pn为第N天该时段快照中IO的使用量。

确定SQL消耗增长指标中的频次及资源消耗指标的增长率时，采用同比的方式，确定SQL消耗增长指标中的频次及资源消耗指标的增长率，即：将每个月同一天的业务模块消耗快照(SQL性能指标快照)相比对，计算与历史表中每月同日同比增长，从而确定出SQL消耗增长指标中的频次及资源消耗指标的增长率，以便更新基线库中的SQL消耗增长指标。

其中，SQL消耗增长指标快照库中的SQL消耗增长指标表征的是指标的消耗量；而基线库中的SQL消耗增长指标表征的是指标的增长量。

对于频次的增长率的计算方法为：

gr＝freq/freq' (3)

其中，freq为当日快照中该SQL频次的值，freq'为上月同日快照中该SQL频次的值。

基线库中，修正频次增长指标的计算方法为：

${\mathrm{gr}}^{\′}=\frac{\mathrm{freq}+{\mathrm{freq}}_1+{\mathrm{freq}}_2+\·\·\·+{\mathrm{freq}}_{n-1}}{{\mathrm{freq}}_1+{\mathrm{freq}}_2+{\mathrm{freq}}_3\·\·\·+{\mathrm{freq}}_n}---\left(4\right)$

其中，freq为当日快照中频次的值，freq1为前一月当日快照中频次的值,freq2为前两月当日快照中频次的值，以此类推，n为快照的样本数。

资源耗指标可以包括：CPU时间指标、执行时间指标、逻辑读指标和物理读指标四种。

以CPU时间指标为例，增长率的计算方法为：

gr＝(cp×freq)/(cp'×freq') (5)

其中，cp和freq分别为当日快照中每次执行所用cpu_time的值和频次的值，cp’和freq’分别为上月同日快照中每次执行所用cpu_time的值和频次的值。其中，cpu_time表示CPU的时长。

基线库中，修正CPU增长指标计算方法为：

${\mathrm{gr}}^{\′}=\frac{\mathrm{cp}\×\mathrm{freq}+{\mathrm{cp}}_1\×{\mathrm{freq}}_1+{\mathrm{cp}}_2\×{\mathrm{freq}}_2+\·\·\·+p_{n-1}\×{\mathrm{freq}}_{n-1}}{{\mathrm{cp}}_1\×{\mathrm{freq}}_1+{\mathrm{cp}}_2\×{\mathrm{freq}}_2+{\mathrm{cp}}_2\×{\mathrm{freq}}_3\·\·\·+{\mathrm{cp}}_n\×{\mathrm{freq}}_n}---\left(6\right)$

其中，cp和freq分别为当日快照中每次执行所用cpu_time的值和频次的值，cp1和freq1分别为前一个月同日快照中每次执行所用cpu_time的值和频次的值，cp2和freq2分别为前两个月同日快照中每次执行所用cpu_time的值和频次的值，以此类推，n为快照的样本数。

其次，进行资源的动态分配。

具体地，如图5所示，所述设备的评估层定时采集(比如每个小时采集一次等)系统的性能指标，并利用每次采集的系统CPU和IO使用情况指标进行当前空闲资源评估，当根据所述空闲资源评估结果，确定数据库系统负载较轻时，利用预估的资源周期性消耗结果，进行空闲资源周期性预估；比如：可以根据基线的相关数据，确认空闲资源的大致周期，便于部署相关应用。

这里，在进行当前空闲资源评估时，当前空闲cpu_time的计算公式为：

c＝c1/c2×(100-R-c1) (7)

其中，c1为当前系统CPU使用百分比，c2为数据库CPU的使用百分比，R为系统CPU预留的百分比常量，值一般可以为15。

当前空闲IO的计算公式为：

p＝p1/p2×(R-p1) (8)

其中，p1为当前系统IO使用，p2为数据库物理读使用量，R为系统IO最大值。

如果所述评估层确定数据库系统的负载过高，且所述设备的队列层确定有正在执行的任务队列中的任务时，为了保证高优先级的应用的正常运行，所述设备的控制层需要暂停任务的执行，并释放相应的资源；此时，需要保存暂停执行的任务的中间状态，以保证后续执行该任务时可以从断点继续执行该任务。

所述队列层根据预估的周期性空闲资源及对应时长，从队列任务基线库的任务队列中匹配出待执行任务；所述控制层利用所述预估的周期性空闲资源执行匹配出的待执行任务。

具体地，所述队列层探测任务队列中的任务，判断是否能匹配出待执行任务，如果能匹配出待执行任务，再判断匹配出的待执行任务是否有断点，如果有断点，则触发所述控制层恢复任务，如果没有断点，则触发所述控制层启动任务。

其中，在匹配待执行任务时，所述队列层将所述任务队列中的待执行任务按照所述队列任务基线库中采集的顺序进行排序；按照排序结果，并根据预估的周期性空闲资源及对应时长，从所述任务队列中依次匹配出所述待执行任务。如果没有匹配出待执行任务，则进行下一次的定时采集。

如果配出的待执行任务有断点，说明曾经执行过该任务，此时进行任务和亏负，如果没有断点，说明该任务未被执行过，直接启动该任务即可。

采用本实施例的方案，可以得到如图6a及图6b所示的CPU及IO的使用情况示意图，从图中可以看出，经过动态调度资源，可以使系统的资源得到合理利用，系统运行状态平稳，较少出现峰值。

另外，由于本实施例建立了快照库和基线库，当业务发生变化时，对应的基线(对应SQL)肯定会发生变化；同理，当基线发生变化时，业务肯定会存在异常，因此实现了SQL与业务模块的双向联动；并且，依赖建立的强大的基线库，可以将SQL性能指标与业务指标关联，按业务模块分组，分析出各业务占用的数据库资源(CPU、物理读、逻辑读等指标均可)比重，建立可视化的资源比重。比如，可以得到如图7a和图7b所示的资源占用比重。从图中可以获知，工单管理、短信下发、空中充值、服务状态变更四个业务模块占用了较多的数据库CPU资源和IO资源。基于此，可以进一步清晰地获知系统的关键业务占用资源比重，占用比重是否合理，对于业务实际使用与资源占用不合理的业务模块，可以从业务出发，成立专题，重新梳理业务流程，并进行优化。其中，在图7a中，A表示工单管理，B表示短信下发，C表示空中充值，D表示服务状态变更，E表示资源调拨，F表示产品创建，G表示用户信息管理，H表示服务请求生成，I表示服务资源变更，J表示账户信息管理，K表示用户资源管理，L表示资源入库管理、M表示客户信息管理，N表示集团成员管理，O表示渠道积分管理。在图7b中，A表示短信下发，B表示工单管理，C表示空中充值，D表示服务状态变更，E表示服务资源变更，F表示产品创建，G表示用户信息管理，，H表示服务流程管理，I表示账户信息管理，J表示资源调拨，K表示用户资源管理，L表示客户信息管理，M表示营销活动管理，N表示渠道缴费管理，O表示资源入库管理。

除此以外，还可根据快照库，分析某一个业务模块的资源占比变化，对于资源占比增长较快的业务模块，可以成立专题分析，避免滚雪球式的性能问题发生。

通过可视化的资源比重模型，进一步加强了业务性能的管理。

由于独立出业务系统能极大地解决负载过高的情况，但是需要额外地投入硬件资源，接口传输代价等，因此拆分决策需要长时间的数据支持。而本发明实施例的方案由于定时采集性能数据及SQL性能数据，并进行相应的分析，因此，能很好地为拆分决策提供支撑，当采集到业务系统消耗占比极大，且系统负载持续过高的情况，为业务系统的拆分提供依据。

从上面的描述中可以看出，本实施例的方案具有以下优点：

(1)避免了对于DBA经验的依赖，无需指定队列任务的具体执行时间，将控制权交由应用本实施例方案的设备自动根据当前系统负载情况自动调度。使系统既不会过于繁忙，也不会过于空闲，合理地利用空闲时段运行队列任务，规避了应用高峰期资源争用的问题，提高了系统的可维护性和高可用性。

(2)启动队列任务之后，当预知范围外的应用高峰到来时，能保存进程(任务)的中间状态，释放进程资源，产生断点。当监控到系统高峰过后，从断点恢复资源，任务继续执行，如此，避免了资源的浪费，提高了系统的利用率。

(3)定时采集业务模块及任务的资源消耗，能清晰地获知系统的关键业务占用资源比重，为业务逻辑检查，系统拆分提供有力依据。

(4)能够评估队列任务的精确消耗，确保执行时不会超过系统的最高负载，有效地避免了此类故障。

实施例三

本实施例基于实施例一、二，本实施例提供一种资源调度装置，如图8所示，该装置包括：第一评估单元81、第二评估单元82、任务匹配单元83及任务执行单元84；其中，

所述第一评估单元81，用于利用当前采集的性能指标，评估空闲资源；所述性能指标表征数据库资源的使用情况；

所述第二评估单元82，用于根据所述空闲资源评估结果确定数据库的负载小于预设值时，利用预估的资源周期性消耗结果，进行空闲资源周期性预估；

所述任务匹配单元83，用于根据预估的周期性空闲资源及对应时长，从队列任务基线库的任务队列中匹配出待执行任务；所述任务队列中的任务是指：与数据库维护相关的任务；

所述任务执行单元84，用于利用所述预估的周期性空闲资源执行匹配出的待执行任务。

其中，所述性能指标可以包括所述数据库的CPU及I/O使用情况指标；相应地，根据CPU指标及IO使用情况指标，进行空闲资源的评估。

当所述数据库的负载小于所述预设值时，说明所述数据库的负载较轻，这种情况下，可以根据需要执行任务队列中的待执行任务；当根据所述空闲资源评估结果确定数据库的负载大于等于预设值时，说明所述数据库负载过重，这种情况下，为了保证高优先级的业务(应用)的正常运行，如果有正在执行的任务队列中的任务时，需要暂停任务的执行，并释放相应的资源；此时，需要保存暂停执行的任务的中间状态，以保证后续执行该任务时可以从断点继续执行该任务。

其中，实际应用时，可以根据需要设置所述预设值。

该装置还可以包括：第三评估单元，用于周期性采集并保存所述性能指标；基于保存的所述性能指标，采用同比和/或环比的方式，得出资源消耗规律；并根据所述资源消耗规律，对所述资源周期性消耗进行预估。

其中，根据所述预估的资源周期性消耗结果，可以估算出未来时间片里的空闲资源及对应的时长。

实际应用时，采集所述性能指标的周期可以根据需要确定，比如可以是一个月等。

实际应用时，可以定时采集所述数据库的性能数据，从这些性能数据中提取CPU及IO的使用情况指标，并建立系统快照，从而实现周期性采集并保存所述性能指标；

相应地，采用同比的方式，得出资源消耗规律具体可以是指：将每个月同一天，每天同一时刻的CPU及IO使用情况的快照相比对，得出系统消耗规律。采用环比的方式，是指：将每天各时段的CPU及IO使用情况的快照相比对，得出系统消耗规律。

这里，所述任务队列中的任务是指：需要执行的任务。

所述任务匹配单元83可以包括：排序模块及任务匹配模块；其中，

所述排序模块，用于将所述任务队列中的待执行任务按照所述队列任务基线库中采集的顺序进行排序；

所述任务匹配模块，用于按照排序结果，并根据预估的周期性空闲资源及对应时长，从所述任务队列中依次匹配出所述待执行任务。

实际应用时，可以定时采集所述性能指标，相应地，每次定时采集的性能指标即为所述第一评估单元81当前采集的性能指标；这种情况下，当从任务队列中未匹配出待执行任务时，则依据规则进行下一次的定时采集性能指标。

实际应用时，所述匹配出的待执行任务的个数可以为一个以上。

该装置还可以包括：基线库建立单元，用于周期性从所述数据库中采集并保存SQL性能指标，并进行对应的业务绑定；

确定保存的SQL性能指标在所述队列任务基线库或应用基线库中不存在对应基线时，在所述队列任务基线库或应用基线库中建立对应的基线；

确定保存的SQL性能指标在所述队列任务基线库或应用基线库中存在对应基线时，采用同比的方式，确定SQL消耗增长指标中的频次及资源消耗指标的增长率；并校正所述对应基线的相关数据。

其中，采集所述SQL性能指标的周期可以根据需要确定，比如可以是：一个小时等。

实际应用时，在采集并保存SQL性能指标时，所述基线库建立单元可以定时从数据库的动态性能视图(V$SQL、V$SQL_PLAN等)中采集SQL性能数据，从这些SQL性能数据中提取SQL性能指标，并建立业务模块消耗快照，从而实现周期性从所述数据库中采集并保存SQL性能指标。其中，V$SQL可以反映存储的SQL语句；V$SQL_PLAN可以反映存储的SQL语句的执行计划。

所述SQL性能指标可以包括：SQL的频次及对应的资源消耗指标；其中，所述资源消耗指标可以包括：每次的CPU使用时间、每次的执行时间、每次的逻辑读、每次的物理读。其中，逻辑读是指从内存里访问数据，物理读是指从磁盘里访问数据。

相应地，采用同比的方式，确定SQL消耗增长指标中的频次及资源消耗指标的增长率是指：将每个月同一天的业务模块消耗快照相比对，从而确定出SQL消耗增长指标中的频次及资源消耗指标的增长率。

这里，在确定增长率时，所述基线库建立单元基于当日的频次及上月同日的频次，并结合保存的样本数，确定频次的增长率；并基于当日的资源消耗指标及上月同日的资源消耗指标，并结合保存的样本数，确定资源消耗指标的增长率。

进行对应的业务绑定的目的是：形成对应基线，以便当基线库中不存在对应基线时，在所述队列任务基线库或应用基线库中建立对应的基线；或者，当基线库中存在对应基线时，确定增长率及校正基线库中对应基线的相关数据。

在进行对应的业务绑定时，当保存的SQL性能指标未在所述队列任务基线库或应用基线库中(即保存的SQL性能指标对应的基线未在所述队列任务基线库或应用基线库中)时，所述基线库建立单元推送到未绑定业务标签列表中，由业务人员打上业务标签后，再回存到基线库，进行对应的业务绑定；对于保存的SQL性能指标已在所述队列任务基线库或应用基线库中的，所述基线库建立单元直接绑定业务标签，即进行对应的业务绑定，并建立业务模块消耗快照。

通过对比已存在的基线的相关数据，即可确定保存的SQL性能指标是否存在对应基线。

所述应用基线库的作用是存储多次在数据库中运行的相关任务信息，以便能从整体了解各任务占用的资源情况。

所述基线的作用可以理解为一个任务的基准线，如果这个基准线波动很大，则说明该任务异常，需要修改、调整等。

实际应用时，所述校正所述对应基线的相关数据的目的是：是为了减小对应任务的基准线，使得基准线波动尽可能的降低。

所述任务执行单元84，具体用于：确定所述匹配出的待执行任务有断点时，利用所述预估的周期性空闲资源从断点处执行所述匹配出的待执行任务；相应地，确定所述匹配出的待执行任务没有断点时，则直接启动匹配出的待执行任务。

其中，可以根据是否保存有暂停执行的任务的中间状态来确定对应待执行任务是否有断点。

所述任务执行单元84，还用于在利用所述预估的周期性空闲资源执行匹配出的待执行任务的过程中，根据利用下一次采集的性能指标得出的所述空闲资源评估结果确定数据库的负载大于等于所述预设值时，暂停任务的执行，释放相应的资源，并保存暂停执行的任务的中间状态。

实际应用时，所述第一评估单元81、第二评估单元82、任务匹配单元83及任务执行单元84、第三评估单元、基线库建立单元、排序模块、以及任务匹配模块可由资源调度装置中的中央处理器(CPU，Central Processing Unit)、微处理器(MCU，Micro Control Unit)、数字信号处理器(DSP，Digital SignalProcessor)或可编程逻辑阵列(FPGA，Field－Programmable Gate Array)结合存储器实现。

本实施例提供的资源调度装置，所述第一评估单元81利用当前采集的性能指标，评估空闲资源；所述性能指标表征数据库资源的使用情况；所述第二评估单元82根据所述空闲资源评估结果确定数据库的负载小于预设值时，利用预估的资源周期性消耗结果，进行空闲资源周期性预估；所述任务匹配单元83根据预估的周期性空闲资源及对应时长，从队列任务基线库的任务队列中匹配出待执行任务；所述任务执行单元84利用所述预估的周期性空闲资源执行匹配出的待执行任务，如此，能及时、有效、准确地进行资源调度。

另外，确定所述匹配出的待执行任务有断点时，利用所述预估的周期性空闲资源从断点处执行所述匹配出的待执行任务，如此，能保证数据状态的一致性，进而节约了资源，提高资源的利用率。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (12)

1.一种资源调度方法，其特征在于，所述方法包括：

利用当前采集的性能指标，评估空闲资源；所述性能指标表征数据库资源的使用情况；根据所述空闲资源评估结果确定数据库的负载小于预设值时，利用预估的资源周期性消耗结果，进行空闲资源周期性预估；

根据预估的周期性空闲资源及对应时长，从队列任务基线库的任务队列中匹配出待执行任务；所述任务队列中的任务为与数据库维护相关的任务；

利用所述预估的周期性空闲资源执行匹配出的待执行任务。

2.根据权利要求1所述的方法，其特征在于，所述利用所述预估的周期性空闲资源执行匹配出的待执行任务时，所述方法还包括：

确定所述匹配出的待执行任务有断点时，利用所述预估的周期性空闲资源从断点处执行所述匹配出的待执行任务。

3.根据权利要求1所述的方法，其特征在于，所述利用所述预估的周期性空闲资源执行匹配出的待执行任务的过程中，所述方法还包括：

根据利用下一次采集的性能指标得出的所述空闲资源评估结果确定数据库的负载大于等于所述预设值时，暂停任务的执行，释放相应的资源，并保存暂停执行的任务的中间状态。

4.根据权利要求1所述的方法，其特征在于，所述利用当前采集的性能指标，评估空闲资源之前，所述方法还包括：

周期性采集并保存所述性能指标；

基于保存的所述性能指标，采用同比和/或环比的方式，得出资源消耗规律；

根据所述资源消耗规律，对所述资源周期性消耗进行预估。

5.根据权利要求1所述的方法，其特征在于，所述根据预估的周期性空闲资源及对应时长，从任务队列中匹配出待执行任务，包括：

将所述任务队列中的待执行任务按照所述队列任务基线库中采集的顺序进行排序；

按照排序结果，并根据预估的周期性空闲资源及对应时长，从所述任务队列中依次匹配出所述待执行任务。

6.根据权利要求1所述的方法，其特征在于，

所述根据预估的周期性空闲资源及对应时长，从队列任务基线库的任务队列中匹配出待执行任务之前，所述方法还包括：

周期性从所述数据库中采集并保存结构化查询语言SQL性能指标，并进行对应的业务绑定；

确定保存的SQL性能指标不存在对应基线时，在所述队列任务基线库或应用基线库中建立对应的基线；或者，

确定保存的SQL性能指标在所述队列任务基线库或应用基线库中存在对应基线时，采用同比的方式，确定SQL消耗增长指标中的频次及资源消耗指标的增长率；并校正所述对应基线的相关数据。

7.根据权利要求6所述的方法，其特征在于，所述采用同比的方式，确定SQL消耗增长指标中的频次及资源消耗指标的增长率，为：

基于当日的频次及上月同日的频次，并结合保存的样本数，确定频次的增长率；并基于当日的资源消耗指标及上月同日的资源消耗指标，并结合保存的样本数，确定资源消耗指标的增长率。

8.一种资源调度装置，其特征在于，所述装置包括：第一评估单元、第二评估单元、任务匹配单元及任务执行单元；其中，

所述第一评估单元，用于利用当前采集的性能指标，评估空闲资源；所述性能指标表征数据库资源的使用情况；

所述第二评估单元，用于根据所述空闲资源评估结果确定数据库的负载小于预设值时，利用预估的资源周期性消耗结果，进行空闲资源周期性预估；

所述任务匹配单元，用于根据预估的周期性空闲资源及对应时长，从队列任务基线库的任务队列中匹配出待执行任务；所述任务队列中的任务为与数据库维护相关的任务；

所述任务执行单元，用于利用所述预估的周期性空闲资源执行匹配出的待执行任务。

9.根据权利要求8所述的装置，其特征在于，所述任务执行单元，具体用于：确定所述匹配出的待执行任务有断点时，利用所述预估的周期性空闲资源从断点处执行所述匹配出的待执行任务。

10.根据权利要求8所述的装置，其特征在于，所述任务执行单元，还用于在利用所述预估的周期性空闲资源执行匹配出的待执行任务的过程中，根据利用下一次采集的性能指标得出的所述空闲资源评估结果确定数据库的负载大于等于所述预设值时，暂停任务的执行，释放相应的资源，并保存暂停执行的任务的中间状态。

11.根据权利要求8所述的装置，其特征在于，所述装置还包括：第三评估单元，用于周期性采集并保存所述性能指标；基于保存的所述性能指标，采用同比和/或环比的方式，得出资源消耗规律；并根据所述资源消耗规律，对所述资源周期性消耗进行预估。

12.根据权利要求8所述的装置，其特征在于，所述装置还可以包括：基线库建立单元，用于周期性从所述数据库中采集并保存SQL性能指标，并进行对应的业务绑定；

确定保存的SQL性能指标不存在对应基线时，根据，在所述队列任务基线库或应用基线库中建立对应的基线；或者，

确定保存的SQL性能指标在所述队列任务基线库或应用基线库中存在对应基线时，采用同比的方式，确定SQL消耗增长指标中的频次及资源消耗指标的增长率；并校正所述对应基线的相关数据。