CN109947619A - 基于服务质量感知提高吞吐量的多资源管理系统及服务器 - Google Patents

Abstract

本发明提供一种基于服务质量感知提高吞吐量的多资源管理系统及服务器，所述基于服务质量感知提高吞吐量的多资源管理系统包括：在线预测器，用于根据预设预测模型预测每个延迟敏感型应用请求在给定资源配置下的运行时间；资源分配器，用于根据预测的所述运行时间为所述延迟敏感型应用请求分配满足服务质量的资源配置；动态QoS监视器，用于确定当前的内存带宽竞争是否会引起QoS违例，并在确定当前的内存带宽竞争会引起QoS违例时对所述资源配置进行调整。本发明在保证延迟敏感型应用的服务质量的提前下，极大提高了批处理任务的吞吐量，有效解决了现有技术中在保证应用的服务质量过程中资源利用率低的问题。

Description

基于服务质量感知提高吞吐量的多资源管理系统及服务器

技术领域

本发明涉及数据服务技术领域，特别是涉及一种基于服务质量感知提高吞吐量的多资源管理系统及服务器。

背景技术

数据中心中延迟敏感型应用((LS，Latency Sensitive)，如网络搜索、网络服务、memcached，保持它们的较低响应延迟，对提升用户体验很必要。因此，为保证这些应用的服务质量(QoS)，经常将它们单独部署在服务器上并为它们提供过量的硬件资源。然而，这些应用一般都有昼夜规律(除了高峰时间，其他时间没有充分利用资源)，所以将它们与批处理任务(BE，没有QoS要求的任务)混合部署是一种经济合理的方式。

然而，由于共享资源的竞争，上述混合部署可能导致LS应用达不到服务质量要求，产生QoS违例(QoS Violation)。先前已有大量的研究者意识到了这个问题，提出了在保证LS 应用QoS的前提下提高资源利用率的方法。这些方法对于单线程的传统LS应用(比如网络搜索)都是有效的，但是在新型的LS应用中(如智能私人助理服务、微软必应搜索、金融服务等)，计算能力需求变大，从而需要更高的并行度才能满足其QoS要求。具体而言，这些应用的处理时间，占据了其端到端延迟的很大一部分。而且在相同的工作负载下，一个长请求的延迟可能是正常请求的数十倍。由于这些因素，已有的方法并不能完全保证QoS，因此在保证这些新型LS应用的QoS的前提下，提高资源利用率成为了一个新的挑战。

现有技术中，一种方式是基于置解决QoS违例，基于置(profile-based)以Bubble为代表，预先考察各应用的特征，并只混合部署“安全”的应用。但是当需要执行这些新型的LS 应用时，基于预配置的方法浪费了一部分潜在的混合部署机会，从而导致了低的资源利用率。假设一个LS应用由多个工作负载不同的请求组成，在这个应用与其他批处理任务混合部署时，会导致一小部分长请求出现QoS违例，从而这个混合部署会被终止，导致硬件利用率的降低。

现有技术中，另种方式是基于反馈解决QoS违例，基于反馈，以Heracles为代表，它们使用历史记录来指导应用的混合部署与资源分配。基于反馈的方法也可能导致QoS违例。在这种方法中，若一个请求的尾延迟(tail-latency)在过去的监测周期中接近或者超过QoS要求，那么系统会将更多的资源分配给这个LS应用；否则，将会减少其拥有的资源。例如，假设在一个监测周期t内，一个LS应用的请求都是短请求，那么在下一个监测周期t+1中系统将减少为其分配的资源。这种情况下，如果在监测周期t+1中请求变化为长请求，那么将发生QoS违例。反之，若是在监测周期t内是长请求，而在t+1内是变为短请求，那么将会有一些不必要的资源分配给这个应用，从而导致低的资源利用率。

发明内容

鉴于以上所述现有技术的缺点，本发明的目的在于提供一种基于服务质量感知提高吞吐量的多资源管理系统及服务器，用于解决现有技术中在保证应用的服务质量过程中资源利用率低的问题。

为实现上述目的及其他相关目的，本发明提供一种基于服务质量感知提高吞吐量的多资源管理系统，所述基于服务质量感知提高吞吐量的多资源管理系统包括：在线预测器，用于根据预设预测模型预测每个延迟敏感型应用请求在给定资源配置下的运行时间；资源分配器，用于根据预测的所述运行时间为所述延迟敏感型应用请求分配满足服务质量的资源配置；动态QoS监视器，用于确定当前的内存带宽竞争是否会引起QoS违例，并在确定当前的内存带宽竞争会引起QoS违例时对所述资源配置进行调整。

于本发明的一实施例中，所述预设预测模型根据内存带宽的工作量、分配的内核数量以及分配的缓存空间大小预测每个延迟敏感型应用请求在给定资源配置下的运行时间。

于本发明的一实施例中，所述预测模型为k-临近算法回归模型，线性回归模型或多层感知神经网络模型。

于本发明的一实施例中，所述延迟敏感型应用请求满足服务质量的资源配置的条件为：

T_p≤T_tgt-T_queued-T_nw；其中：T_p为运行时间，T_tgt为服务质量目标，T_queued为实时排队延迟， T_nw为实时网络通信时间；T_queued＝T_start-T_sub，T_start为延迟敏感型应用请求开始运行的时间，T_sub为延迟敏感型应用请求被提交的时间。

于本发明的一实施例中，所述分配满足服务质量的资源配置的一种实现方式包括：将分配给延迟敏感型应用请求的共享缓存路数固定为最大值；查找使所述延迟敏感型应用请求满足服务质量的最小内核数量值；当确定所述最小内核数量值之后，寻找最小的共享缓存路数。

于本发明的一实施例中，所述确定当前的内存带宽竞争是否会引起QoS违例的一种实现方式包括：定期收集所述延迟敏感型应用请求的实际IPC；获取最小的IPC；根据所述实际 IPC、所述最小的IPC以及IPC周期获取滞后因子；判断所述滞后因子是否大于1，在所述滞后因子大于1时，确定当前的内存带宽竞争引起QoS违例。

于本发明的一实施例中，所述获取最小的IPC的一种方式为：

其中，IPC_req为最小的IPC，W_all为总的工作量，W_cmpl为已完成的工作量，T_tgt为服务质量目标，T_qusued为实时排队延迟，T_nw为实时网络通信时间，T_run为实际运行时间。

于本发明的一实施例中，所述根据所述实际IPC、所述最小的IPC以及IPC周期获取滞后因子的一种方式为：其中，F为滞后因子，IPC_req为最小的IPC，IPC_current为实际IPC，IPC_pred为IPC周期。

于本发明的一实施例中，所述在确定当前的内存带宽竞争会引起QoS违例时对所述资源配置进行调整包括：线性增加分配给所述延迟敏感型应用请求的原有核数量或原有共享缓存空间；或者通过以下方式为所述延迟敏感型应用请求分配新的内核数量或新的共享缓存空间：分配的新的内核数量为：r_core×F+max{1,(F-1)×r_core}；其中，r_core为原有内核数量；分配的新的共享缓存空间为：r_cachec×F+max{1,(F-1)×r_cache}；其中，r_cachec为原有共享缓存空间。

本发明的实施例还提供一种服务器：所述服务器包括如上所述的基于服务质量感知提高吞吐量的多资源管理系统。

如上所述，本发明的一种基于服务质量感知提高吞吐量的多资源管理系统及服务器，具有以下有益效果：

1、本发明提供了一套应用于数据中心的、基于服务质量感知提高吞吐量的多资源管理系统，建立了一个包含线预测器、资源分配器、动态QoS监视器的系统，在保证延迟敏感型应用的服务质量的提前下，极大提高了批处理任务的吞吐量，有效解决了现有技术中在保证应用的服务质量过程中资源利用率低的问题。

2、本发明的成果可以有效应对日益增多的新型多线程延迟敏感型应用(如智能私人助理服务、微软必应搜索、金融服务)的服务质量要求。

3、本发明的成果可以在私有数据中心中构建具有经济效益的、支持延迟敏感型应用与批处理任务有效混合部署的多资源管理系统。

附图说明

图1显示为本发明的一实施例中基于服务质量感知提高吞吐量的多资源管理系统的整体原理结构图。

图2显示为本发明的一实施例中基于服务质量感知提高吞吐量的多资源管理系统的应用架构图。

元件标号说明

100 基于服务质量感知提高吞吐量的多资源管理系统

110 在线预测器

120 资源分配器

130 动态QoS监视器

具体实施方式

以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。

请参阅图1至图2。须知，本说明书所附图式所绘示的结构、比例、大小等，均仅用以配合说明书所揭示的内容，以供熟悉此技术的人士了解与阅读，并非用以限定本发明可实施的限定条件，故不具技术上的实质意义，任何结构的修饰、比例关系的改变或大小的调整，在不影响本发明所能产生的功效及所能达成的目的下，均应仍落在本发明所揭示的技术内容得能涵盖的范围内。同时，本说明书中所引用的如“上”、“下”、“左”、“右”、“中间”及“一”等的用语，亦仅为便于叙述的明了，而非用以限定本发明可实施的范围，其相对关系的改变或调整，在无实质变更技术内容下，当亦视为本发明可实施的范畴。

本发明实施例的目的在于提供一种基于服务质量感知提高吞吐量的多资源管理系统100 及服务器，用于解决现有技术中在保证应用的服务质量过程中资源利用率低的问题。

在面对新型延迟敏感型应用(LS，Latency Sensitive)应用时，已有技术的弱点让我们开始根据系统负载和请求自身的计算特性为每个请求分配资源。研究表明，实现上述目标有下述几个挑战。首先，每个延迟敏感型应用请求有着不同的工作负载、实时队列延迟和网络通信时间(即系统负载)，因此为了满足QoS，每个请求需要不同的资源数量。其次，由于多种资源(核、共享缓存、内存带宽)会被混合部署的应用共享(在这里没有考虑IO竞争，因为LS应用会将数据缓存在内存中，因此不会与批处理任务竞争IO带宽)，如何在运行时为一个请求分配最恰当的资源是一个多维难题。最后，内存带宽竞争也可能会导致QoS违例，但是当前的操作系统并未提供一个可以明确分配内存带宽的方法。

为了应对上述三个挑战，本实施例提出了基于服务质量感知提高吞吐量的自适应多资源管理系统(Avalon)，它由在线预测器110、资源分配器120、动态QoS监视器130组成。预测器利用一个新颖的模型来预测每个LS请求在不同资源配置(核的数量核共享缓存空间) 下的执行时间。基于这个准确的预测时间，资源分配器120为该LS请求分配恰好足够的资源使其能够满足QoS。而为了解决第三个挑战，QoS监视器将会监视每个请求的执行过程，如果发现由于内存带宽竞争而运行过慢、达不到QoS要求，监视器将会为其分配更多的核以及更大的共享缓存空间来加速该请求的执行。通过精确的工作负载感知和多资源管理，实施例中的基于服务质量感知提高吞吐量的自适应多资源管理系统(Avalon)确保了新型LS应用能够满足QoS要求。

以下将详细阐述本实施例的一种基于服务质量感知提高吞吐量的多资源管理系统100及服务器的原理及实施方式，使本领域技术人员不需要创造性劳动即可理解本实施例的一种基于服务质量感知提高吞吐量的多资源管理系统100及服务器。

如图1所示，本实施例提供本发明提供一种基于服务质量感知提高吞吐量的多资源管理系统100，所述基于服务质量感知提高吞吐量的多资源管理系统100包括：在线预测器110，资源分配器120以及动态QoS监视器130。

以下对本实施例中的在线预测器110，资源分配器120以及动态QoS监视器130进行详细说明。

于本实施例中，所述在线预测器110用于根据预设预测模型预测每个延迟敏感型应用请求在给定资源配置下的运行时间。

具体地，于本实施例中，所述预设预测模型根据但不限于内存带宽的工作量、分配的内核数量以及分配的缓存空间大小预测每个延迟敏感型应用请求在给定资源配置下的运行时间。

例如，所述基于服务质量感知提高吞吐量的多资源管理系统100(Avalon)中的在线预测器110选择三个明显影响请求运行时间的代表性特征——工作量、分配的内核数量、分配的缓存空间大小——来进行预测。

当一个延迟敏感型应用请求(LS请求)到达时，所述在线预测器110将会使用离线训练的预测模型预测其在给定资源配置下的运行时间和执行速度(使用每周期执行指令数来度量)。

其中，所述预测模型为单不限于k-临近算法回归模型，线性回归模型或多层感知神经网络模型。

所述基于服务质量感知提高吞吐量的多资源管理系统100(Avalon)使用低开销的回归模型(k-临近算法(KNN)，线性回归(LR)，多层感知神经网络(NN))来进行预测，这些预测模型能够在十分之一毫秒级的时间内完成预测，并达到超过80％的预测准确率。在预配置阶段，所述基于服务质量感知提高吞吐量的多资源管理系统100可以为每一类型的延迟敏感型应用选择最适配的模型。

于本实施例中，所述资源分配器120用于根据预测的所述运行时间为所述延迟敏感型应用请求分配满足服务质量的资源配置。

当所述延迟敏感型应用请求开始运行时，资源分配器120会为该所述延迟敏感型应用请求寻找一个最佳资源配置，使其达到QoS目标。这个资源配置由排队延迟、网络通信时间、不同资源配置下所预测的运行时间共同决定。

具体地，于本实施例中，所述延迟敏感型应用请求满足服务质量的资源配置的条件为：

T_p≤T_tgt-T_queued-T_nw；其中：T_p为运行时间，T_tgt为服务质量目标，T_queued为实时排队延迟， T_nw为实时网络通信时间；T_queued＝T_start-T_sub，T_start为延迟敏感型应用请求开始运行的时间，T_sub为延迟敏感型应用请求被提交的时间。

实际上，一个延迟敏感型应用请求的端到端延迟由排队延迟和实际运行时间组成。对于延迟敏感型应用请求(例如以下以q指代)，本实施例使用T_tgt,T_queued,T_nw,T_p分别表示QoS目标、实时排队延迟、实时网络通信时间与实际运行时间，当且仅当T_nw+T_queued+T_p≤T_tgt时，延迟敏感型应用请求q可以达到QoS目标。其中，T_queued可以使用T_start-T_sub得出，其中T_start是q开始运行的时间，T_sub是q被提交的时间。换言之，只有当下式被满足时，q才能满足QoS目标。而当q开始运行时，T_tgt,T_queued,T_nw,T_p都是已知的。

T_p≤T_tgt-T_queued-T_nw＝T_tgt-(T_start-T_sub)-T_nw；

通过将T_tgt-T_queued-T_nw与在不同资源配置下预测的运行时间进行比较，基于服务质量感知提高吞吐量的多资源管理系统100(Avalon)可以为请求q确定满足QoS的“安全”的资源配置。

于本实施例中，所述分配满足服务质量的资源配置的一种实现方式包括：

将分配给延迟敏感型应用请求的共享缓存路数固定为最大值；

查找使所述延迟敏感型应用请求满足服务质量的最小内核数量值；

当确定所述最小内核数量值之后，寻找最小的共享缓存路数。

为了快速搜索到恰能满足请求QoS的资源配置，基于服务质量感知提高吞吐量的多资源管理系统100(Avalon)使用了二分搜索法。我们将优先减少r_core(表示分配给请求的内核数量)，因为核数量对请求的性能影响较大。首先将r_cache(表示分配给请求的共享缓存路数) 固定为最大值，然后使用二分查找的方法查找使q满足QoS的最小r_core值。当r_core确定之后，再寻找最小的r_cache。在这个算法中，一种资源配置是否会导致请求发生QoS违例，可以使用式T_p≤T_tgt-T_queued-T_nw＝T_tgt-(T_start-T_sub)-T_nw来确定，其中T_p使用在线预测器110的预测值。

二分搜索算法可以轻易的扩展到未来拥有更多中了可分配共享资源的情况中。使用一个k 元组＜r₁,...,r_k＞来表示有k种可分配资源的资源配置，其中r_i表示分配给请求q的第i种资源的数量。在该元组中，各分量是按照对LS应用性能的影响大小降序排列的。算法将会优先寻找序号较小的资源的最小数量。

于本实施例中，所述动态QoS监视器130用于确定当前的内存带宽竞争是否会引起QoS违例，并在确定当前的内存带宽竞争会引起QoS违例时对所述资源配置进行调整。

当资源分配器120为请求分配资源后，请求在运行时还可能会因为不可控的内存带宽竞争而发生QoS违例。因此，动态QoS监视器130会再次微调分配给请求的资源数量来避免QoS发生违例。在请求q的运行期间，QoS监视器通过减少为批处理任务分配的核数量来避免内存带宽竞争。这个方法是可行的，因为分配给应用的核数量与该应用使用的内存带宽是正相关的。

具体地，于本实施例中，所述确定当前的内存带宽竞争是否会引起QoS违例的一种实现方式包括：

定期收集所述延迟敏感型应用请求的实际IPC；

获取最小的IPC；

根据所述实际IPC、所述最小的IPC以及IPC周期获取滞后因子；

判断所述滞后因子是否大于1，在所述滞后因子大于1时，确定当前的内存带宽竞争引起 QoS违例。

其中，于本实施例中，所述获取最小的IPC的一种方式为：

其中，IPC_req为最小的IPC，W_all为总的工作量，W_cmpl为已完成的工作量，T_tgt为服务质量目标，T_qusued为实时排队延迟，T_nw为实时网络通信时间，T_run为实际运行时间。

动态QoS监视器130会确认当前的内存带宽竞争是否会引起QoS违例，并定期微调资源分配情况。为了发现潜在的QoS违例，QoS监视器会定期收集请求q的实际IPC(记为IPC_current)、实际运行时间T_run和已完成的工作量(记为W_cmpl，使用算法一第二步在线计算)。通过以上数据，计算出了最小的IPC(记为IPC_req)，使得请求 q可以满足QoS目标。

显然，若IPC_current＜IPC_req，那么请求q将不能满足QoS目标。此外，若IPC_current＜IPC_pred，意味着在当前资源配置下请求q的实际执行速度也低于预期的执行速度，即资源分配器120 给出的“恰好足够”的资源配置因为内存带宽竞争而变成了“不够用“。

于本实施例中，所述根据所述实际IPC、所述最小的IPC以及IPC周期获取滞后因子的一种方式为：

其中，F为滞后因子，IPC_req为最小的IPC，IPC_current为实际IPC，IPC_pred为IPC周期。

上式计算了一个滞后因子(记为F)来统一这两种情况。若F>1，内存带宽竞争将会导致 q发生QoS违例，QoS监视器则会为q分配更多资源来加速其执行。

在每一个调节周期，QoS监视器会微调每个活跃请求的资源分配。若F>1，QoS监视器将会增加为其分配的共享资源，同时包括核数量与缓存大小。这是因为若不同时增加请求q 的共享缓存空间，那么其执行速度不会得到明显提升。而当请求q对数据比较敏感时，这一效果将更为明显。

具体地，于本实施例中，所述在确定当前的内存带宽竞争会引起QoS违例时对所述资源配置进行调整包括：

线性增加分配给所述延迟敏感型应用请求的原有核数量或原有共享缓存空间；或者通过以下方式为所述延迟敏感型应用请求分配新的内核数量或新的共享缓存空间：分配的新的内核数量为：r_core×F+max{1,(F-1)×r_core}；其中，r_core为原有内核数量；分配的新的共享缓存空间为：r_cachec×F+max{1,(F-1)×r_cache}；其中，r_cachec为原有共享缓存空间。

在确定当前的内存带宽竞争会引起QoS违例时，一个简单的调整方法是在当F>1时，线性增加分配给请求q的核数量或共享缓存空间。然而，根据Amdahl定律，并行应用的IPC 往往与核数量或者共享缓存空间大小呈亚线性增长关系，线性增加分配给q的核数量或者共享缓存空间并不能使q的IPC增加至IPC_req。因此，若F>1，QoS监视器将会为q分配新的资源：

分配的新的内核数量为：r_core×F+max{1,(F-1)×r_core}；

分配的新的共享缓存空间为：r_cachec×F+max{1,(F-1)×r_cache}。

得益于这个额外增加的核数量与共享缓存空间，请求q的IPC一般会在调整之后达到 IPC_req。

本发明的实施例还提供一种服务器：所述服务器包括如上所述的基于服务质量感知提高吞吐量的多资源管理系统100。上述已经对所述基于服务质量感知提高吞吐量的多资源管理系统100进行了详细说明，在此不再赘述。

此外，为了突出本发明的创新部分，本实施例中并没有将与解决本发明所提出的技术问题关系不太密切的技术特征引入，但这并不表明本实施例中不存在其它的结构和功能特征。

需要说明的是，本实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

如图2所示，图2本实施例应用的系统架构示意图。一个集群级的请求分发器接收了用户请求并且分发到数据中心的各节点上，每个节点上部署的基于服务质量感知提高吞吐量的多资源管理系统100(Avalon)负责管理本节点上的资源，每一节点上的基于服务质量感知提高吞吐量的多资源管理系统100(Avalon)均包含在线预测器110、资源分配器120、动态 QoS监视器130三部分。

基于服务质量感知提高吞吐量的多资源管理系统100(Avalon)通过以下三个步骤来提高资源利用率并保证LS应用的QoS：

1)延迟敏感型应用请求(LS请求)(以下以请求q指代)到达时，对其输入进行解析，并输入性能预测器。对每一可能的资源配置(即分配给请求的核数量以及共享缓存空间大小)，预测请求的运行时间和执行速度。

2)请求q开始运行时，资源分配器120会寻找一个刚好满足其QoS的资源配置，并按此为请求q分配资源。在作上述寻找时，也会考虑排队延迟与网络通信时间(系统负载)。如果有大量的请求同时被激活，资源分配器120会为每一个请求执行上述操作。而当每个请求分配到所需资源后，会将剩余的核以及共享缓存分配给批处理(BE)任务。

3)Avalon使用QoS监视器来解决应用在实际混合运行时候产生的内存带宽竞争问题(单个LS应用在与其他应用混合运行的时候将由于内存带宽竞争而执行变慢，为继续满足其QoS 必须在运行时保持资源动态调整)。

值得指出的是，由于基于服务质量感知提高吞吐量的多资源管理系统100(Avalon)单独地为每个请求分配资源，它可以同时管理大量有不同QoS目标的请求。当一个延迟敏感型应用请求(LS请求)到达时，基于服务质量感知提高吞吐量的多资源管理系统100(Avalon) 会预测其所需的资源，并在不影响其他LS请求的同时，抢占批处理任务的资源。

此外，基于服务质量感知提高吞吐量的多资源管理系统100(Avalon)也可以避免由系统负载变化引起的QoS违例。当系统负载发生变化时，每个延迟敏感型应用请求(LS请求) 的排队延迟也会随之变化。这种情况下，基于服务质量感知提高吞吐量的多资源管理系统100 (Avalon)的资源分配器120会为请求延迟敏感型应用请求(LS请求)再次寻找资源配置，使得端到端延迟(运行时间+排队延迟+网络通信时间)小于QoS目标。若系统负载较高，可能会出现为满足LS应用的QoS，而抢占批处理任务所有资源的情况。

综上所述，本发明提供了一套应用于数据中心的、基于服务质量感知提高吞吐量的多资源管理系统100，建立了一个包含线预测器、资源分配器120、动态QoS监视器130的系统，在保证延迟敏感型应用的服务质量的提前下，极大提高了批处理任务的吞吐量，有效解决了现有技术中在保证应用的服务质量过程中资源利用率低的问题；本发明的成果可以有效应对日益增多的新型多线程延迟敏感型应用(如智能私人助理服务、微软必应搜索、金融服务) 的服务质量要求；本发明的成果可以在私有数据中心中构建具有经济效益的、支持延迟敏感型应用与批处理任务有效混合部署的多资源管理系统。所以，本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。

上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。

Claims (10)

1.一种基于服务质量感知提高吞吐量的多资源管理系统，其特征在于：所述基于服务质量感知提高吞吐量的多资源管理系统包括：

在线预测器，用于根据预设预测模型预测每个延迟敏感型应用请求在给定资源配置下的运行时间；

资源分配器，用于根据预测的所述运行时间为所述延迟敏感型应用请求分配满足服务质量的资源配置；

动态QoS监视器，用于确定当前的内存带宽竞争是否会引起QoS违例，并在确定当前的内存带宽竞争会引起QoS违例时对所述资源配置进行调整。

2.根据权利要求1所述的基于服务质量感知提高吞吐量的多资源管理系统，其特征在于：所述预设预测模型根据内存带宽的工作量、分配的内核数量以及分配的缓存空间大小预测每个延迟敏感型应用请求在给定资源配置下的运行时间。

3.根据权利要求1或2所述的基于服务质量感知提高吞吐量的多资源管理系统，其特征在于：所述预测模型为k-临近算法回归模型，线性回归模型或多层感知神经网络模型。

4.根据权利要求1所述的基于服务质量感知提高吞吐量的多资源管理系统，其特征在于：所述延迟敏感型应用请求满足服务质量的资源配置的条件为：

T_p≤T_tgt-T_queued-T_nw；

其中：T_p为运行时间，T_tgt为服务质量目标，T_queued为实时排队延迟，T_nw为实时网络通信时间；T_queued＝T_start-T_sub，T_start为延迟敏感型应用请求开始运行的时间，T_sub为延迟敏感型应用请求被提交的时间。

5.根据权利要4所述的基于服务质量感知提高吞吐量的多资源管理系统，其特征在于：所述分配满足服务质量的资源配置的一种实现方式包括：

将分配给延迟敏感型应用请求的共享缓存路数固定为最大值；

查找使所述延迟敏感型应用请求满足服务质量的最小内核数量值；

当确定所述最小内核数量值之后，寻找最小的共享缓存路数。

6.根据权利要1所述的基于服务质量感知提高吞吐量的多资源管理系统，其特征在于：所述确定当前的内存带宽竞争是否会引起QoS违例的一种实现方式包括：

定期收集所述延迟敏感型应用请求的实际IPC；

获取最小的IPC；

根据所述实际IPC、所述最小的IPC以及IPC周期获取滞后因子；

判断所述滞后因子是否大于1，在所述滞后因子大于1时，确定当前的内存带宽竞争引起QoS违例。

7.根据权利要6所述的基于服务质量感知提高吞吐量的多资源管理系统，其特征在于：所述获取最小的IPC的一种方式为：

其中，IPC_req为最小的IPC，W_all为总的工作量，W_cmpl为已完成的工作量，T_tgt为服务质量目标，T_qusued为实时排队延迟，T_nw为实时网络通信时间，T_run为实际运行时间。

8.根据权利要7所述的基于服务质量感知提高吞吐量的多资源管理系统，其特征在于：所述根据所述实际IPC、所述最小的IPC以及IPC周期获取滞后因子的一种方式为：

其中，F为滞后因子，IPC_req为最小的IPC，IPC_current为实际IPC，IPC_pred为IPC周期。

9.根据权利要8所述的基于服务质量感知提高吞吐量的多资源管理系统，其特征在于：所述在确定当前的内存带宽竞争会引起QoS违例时对所述资源配置进行调整包括：

线性增加分配给所述延迟敏感型应用请求的原有核数量或原有共享缓存空间；或者通过以下方式为所述延迟敏感型应用请求分配新的内核数量或新的共享缓存空间：

分配的新的内核数量为：r_core×F+max{1,(F-1)×r_core}；其中，r_core为原有内核数量；

分配的新的共享缓存空间为：r_cachec×F+max{1,(F-1)×r_cache}；其中，r_cachec为原有共享缓存空间。

10.一种服务器：其特征在于：所述服务器包括如权利要求1至权利要求9所述的基于服务质量感知提高吞吐量的多资源管理系统。