CN106874102A - 基于容器工作性质的资源调度方法和装置 - Google Patents

Abstract

本发明公开了一种基于容器工作性质的资源调度方法和装置，所述方法包括：对宿主机中各容器进行监视；统计当前统计分析周期时间内各个容器的IO信息，判断容器的工作性质是IO密集型还是非IO密集型；将不同类型的容器放入不同的队列中，采用不同的调度策略。本发明所述方法和装置，针对不同容器对IO操作和CPU计算需求上的差异，分别进行资源调度，在降低IO请求延迟的同时提供了足够的CPU时间用于处理IO请求，并且额外开销较小，具有良好的可适性。

Description

基于容器工作性质的资源调度方法和装置

技术领域

本发明涉及互联网技术领域，尤其涉及一种基于容器工作性质的资源调度方法和装置。

背景技术

LXC(Linux Container)容器是一种内核虚拟化技术，可以提供轻量级的虚拟化，以便隔离进程和资源，而且不需要提供指令解释机制以及全虚拟化的其他复杂性。相当于C++中的命名空间(Name Space)。容器有效地将由单个操作装置管理的资源划分到孤立的组中，以更好地在孤立的组之间平衡有冲突的资源使用需求。

Docker项目的目标是实现轻量级的操作装置虚拟化解决方案。在LXC的基础上，Docker进行了进一步的封装，让用户不需要去关心容器的管理，操作Docker的容器就像操作快速轻量级的虚拟机一样简单。

Docker和传统虚拟化(KVM、XEN等)方式的不同之处在于：容器是在操作装置层面上实现虚拟化，直接复用本地主机的操作装置，而传统方式则是在硬件的基础上，虚拟出自己的装置，再在装置上部署相关的APP应用。如图1所示，跟传统VM比较具有如下优点：1)操作启动快；2)轻量级虚拟化；3)开源免费；4)前景及云支持。

Docker核心解决的问题是利用LXC来实现类似VM的功能，从而利用更加节省的硬件资源供给用户更多的计算机资源。随着Docker的发展，在一台Docker宿主机中启动的容器越来越多。而且，Docker宿主机内部的容器数量和状态经常发生变化。如何对其进行性能管理及体验保证成为越来越需要关注的问题。

现有技术中，宿主机中的容器既有I/O方面的任务也有数据处理等方面的任务。传统的资源调度方法把公平性放在第一位，将I/O任务和CPU任务等同对待，导致I/O效率低下。针对这种情况，提出了多种优化方法，例如将任务划分为纯I/O操作和纯CPU计算，没有考虑到I/O操作也需要CPU处理，影响I/O任务的效率；另一方面，容器的工作性质只能在初始化过程中进行指定，但是，容器在运行时也可能会改变成为其它性质，此时则无法对调度策略进行调整。

综上所述，现有方法可以在一定程度上改善I/O延迟，但是不能适应容器的动态变化，同样会影响其I/O性能。

发明内容

鉴于上述问题，提出了本发明以便提供一种基于容器工作性质的资源调度方法和装置，用以克服上述问题或者至少部分地解决或者减缓上述问题的I/O性能缺陷。

根据本发明的一个方面，提供了一种基于容器工作性质的资源调度方法，包括一种基于容器工作性质的资源调度方法，包括：对宿主机中各容器进行监视；统计当前统计分析周期时间内各个容器的IO信息，判断容器的工作性质是IO密集型还是非IO密集型；将不同类型的容器放入不同的队列中，采用不同的调度策略。

可选地，所述对宿主机中各容器进行监视包括：

扫描宿主机内的容器，为每个容器配置对应的进程；

各个进程同步抽取各自容器的状态信息；

对各容器的状态信息进行处理，得到监控信息；

将所有容器的监控信息汇总到数据队列中，每个容器的监控信息利用容器标识进行区分。

可选地，所述统计当前统计分析周期时间内各个容器的IO信息，判断容器的工作性质是IO密集型还是非IO密集型包括：

将各容器的中断频率按照从高到低进行排列，将中断频率高于平均值的容器判断为IO密集型，将中断频率低于平均值的容器判断为非IO密集型。

可选地，所述将不同类型的容器放入不同的队列中，采用不同的调度策略包括：

将IO密集型的容器放入IO密集型队列中，将非IO密集型的容器放入非IO密集型队列中。

可选地，所述将IO密集型的容器放入IO密集型队列中，将非IO密集型的容器放入非IO密集型队列中进一步包括：

在连续几个统计分析周期中都判断为IO密集型容器的情况下才将其放入IO密集型队列中。

可选地，所述将不同类型的容器放入不同的队列中，采用不同的调度策略包括：

降低IO密集型队列的CPU时间片调整周期；

保持非IO密集型队列的CPU时间片调整周期。

可选地，所述将不同类型的容器放入不同的队列中，采用不同的调度策略包括：

根据根据IO密集型队列中各容器的实时CPU空闲率之和动态调度时间片。

根据本发明的另一个方面，提供了一种基于容器工作性质的资源调度装置，包括：监控模块，对宿主机中各容器进行监视；判断模块，统计当前统计分析周期时间内各个容器的IO信息，判断容器的工作性质是IO密集型还是非IO密集型；调度模块，将不同类型的容器放入不同的队列中，采用不同的调度策略。

可选地，所述监控模块包括：

扫描子模块，扫描宿主机内的容器，为每个容器配置对应的进程；

抽取子模块，各个进程同步抽取各自容器的状态信息；

处理子模块，对各容器的状态信息进行处理，得到监控信息；

汇总子模块，将所有容器的监控信息汇总到数据队列中，每个容器的监控信息利用容器标识进行区分。

可选地，所述判断模块，将各容器的中断频率按照从高到低进行排列，将中断频率高于平均值的容器判断为IO密集型，将中断频率低于平均值的容器判断为非IO密集型。

可选地，所述调度模块，将IO密集型的容器放入IO密集型队列中，将非IO密集型的容器放入非IO密集型队列中。

可选地，所述调度模块在连续几个统计分析周期中都判断为IO密集型容器的情况下才将其放入IO密集型队列中。

可选地，所述调度模块将不同类型的容器放入不同的队列中，采用不同的调度策略包括：

降低IO密集型队列的CPU时间片调整周期；

保持非IO密集型队列的CPU时间片调整周期。

可选地，所述调度模块将不同类型的容器放入不同的队列中，采用不同的调度策略包括：

根据根据IO密集型队列中各容器的实时CPU空闲率之和动态调度时间片。

本发明实施例所述基于容器工作性质的资源调度方法和装置，针对不同容器对IO操作和CPU计算需求上的差异，分别进行资源调度，在降低IO请求延迟的同时提供了足够的CPU时间用于处理IO请求，并且额外开销较小，具有良好的可适性。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示意性示出了VM技术和容器技术对比示意图；

图2示意性示出了根据本发明一个实施例的基于容器工作性质的资源调度方法的流程图；

图3示意性示出了根据本发明一个实施例的对宿主机中各容器进行监视的流程图；

图4示意性示出了根据本发明一个实施例的基于容器工作性质的资源调度装置的框图；

图5示意性示出了根据本发明一个实施例的监控模块的框图。

具体实施例

下面结合附图和具体的实施方式对本发明作进一步的描述。

图2示意性示出了根据本发明一个实施例的基于容器工作性质的资源调度方法的流程图，如图2所示，包括以下步骤：

步骤101，对宿主机中各容器进行监视；

如图3所示，在本实施例中，对宿主机中各容器进行监视包括以下子步骤：

步骤1011，扫描宿主机内的容器，为每个容器配置对应的进程；

具体地，在宿主机内部启动本地监控程序，定时扫描宿主机内处于存活状态的主机，为其创建对应的进程，并将容器名称记录在容器列表中。通过上述步骤，创建多个进程，并行执行以获取各个容器的监控信息。

步骤1012，各个进程同步抽取各自容器的状态信息；

各个进程抽取的状态信息包含但不限于以下几种：cpu状态信息、内存状态信息、网络状态信息以及磁盘状态信息，这几种信息是反映容器运行状态的关键指标信息。

Docker宿主机内具有一指定目录cgroup，cgroup目录下有一些文件是实时更新的，cpu状态信息和内存状态信息可通过读取这些文件记录的数据得到。

所述进程在Docker应用容器引擎的指定目录cgroup下抽取所述宿主机内部所有cpu的中断值；所述进程获取对应的容器所占用的cpu总中断值；以及根据所述宿主机的cpu共享策略，对所述容器所占用的cpu总中断值进行处理得到所述容器的cpu占用信息。

步骤1013，对各容器的状态信息进行处理，得到监控信息；

各个进程处理得到的监控信息包含但不限于以下几种：IO信息、CPU信息。

其中，IO信息的统计与监控如下，通过这些统计项统计、监控进程的IO情况。

blkio.reset_stats：重置统计信息，写入一个int值即可。

blkio.time：统计cgroup对设备的访问时间，按格式device_types:node_numbers milliseconds读取信息即可，以下类似。

blkio.io_serviced：统计cgroup对特定设备的IO操作(包括read、write、sync及async)次数，格式device_types:node_numbers operationnumber

blkio.sectors：统计cgroup对设备扇区访问次数，格式device_types:node_numbers sector_count

blkio.io_service_bytes：统计cgroup对特定设备IO操作(包括read、write、sync及async)的数据量，格式device_types:node_numbersoperation bytes

blkio.io_queued：统计cgroup的队列中对IO操作(包括read、write、sync及async)的请求次数，格式number operation

blkio.io_service_time：统计cgroup对特定设备的IO操作(包括read、write、sync及async)时间(单位为ns)，格式device_types:node_numbers operation time

blkio.io_merged：统计cgroup将BIOS请求合并到IO操作(包括read、write、sync及async)请求的次数，格式number operation

blkio.io_wait_time：统计cgroup在各设备中各类型IO操作(包括read、write、sync及async)在队列中的等待时间(单位ns)，格式device_types:node_numbers operation time。

其中，CPU信息的统计与监控如下，

cpuacct–CPU资源报告，这个子系统的配置是cpu子系统的补充，提供CPU资源用量的统计，时间单位都是纳秒。

1.cpuacct.usage：统计cgroup中所有task的cpu使用时长；

2.cpuacct.stat：统计cgroup中所有task的用户态和内核态分别使用cpu的时长；

3.cpuacct.usage_percpu：统计cgroup中所有task使用每个cpu的时长。

步骤1014，将所有容器的监控信息汇总到数据队列中，每个容器的监控信息利用容器标识进行区分。

步骤102，统计当前统计分析周期时间内各个容器的IO信息，判断容器的工作性质是IO密集型还是非IO密集型。

本实施例中，基于CFQ(Completely Fair Queuing，完全公平队列调度)按权重分配各个容器所能占用总体资源的百分比。

根据容器IO操作的中断频率判断所述容器的工作性质是否为IO密集型，将各容器的中断频率按照从高到低进行排列，将中断频率高于平均值的容器判断为IO密集型，将中断频率低于平均值的容器判断为非IO密集型。

步骤103，将不同类型的容器放入不同的队列中，采用不同的调度策略；进入下一个统计分析周期，将所述下一个统计分析周期作为新的统计分析周期，重新执行步骤102。

具体地，将IO密集型的容器放入IO密集型队列中，将非IO密集型的容器放入非IO密集型队列中；其中，非IO密集型队列采用默认调度算法；而IO密集型队列采用下列算法：

为了保持时间片的变化的稳定，减少性能颠簸，可以在容器连续几个统计分析周期中都判断为IO密集型的情况下才将其放入IO密集型队列中。可以使用老化算法来获取平滑后的IO操作终端频率。

具体地，可以将IO密集型容器的CPU时间片调整周期通过cpu.cfs_period_us设定为10ms，将非IO密集型的CPU时间片调整周期通过cpu.cfs_period_us设定为30ms。

这样，在一个统计分析周期内，IO密集型容器运行的总时间没有发生变化，但是调度的频率增加了，在保证公平的前提下，对IO请求的响应加快了。

但是，随着调度频率的增加，上下文切换的消耗也会增加，降低CPU处理效率，进而影响CPU密集型容器的性能。可以采用动态调度时间片的方法，根据根据IO密集型队列中各容器的实时CPU空闲率之和调度时间片。例如，将CPU空闲率之和从0％到100％映射到时间片的30ms到10ms区间内。CPU空闲率虽然在一段时间内相对稳定，但是在相邻的几个统计分析内会不停的变化，如果不停的改变时间片的大小也会造成性能颠簸。所以只有在连续几个统计分析周期CPU空闲率都处于某个范围的时候才会修改时间片大小。另一方面，在实际运行当中，这一统计分析周期之前一段时间的CPU空闲率也应该纳入考虑范围，这样可以减少CPU空闲率突变带来的误差。可以使用老化算法来获取平滑后的CPU空闲率。

可选的，可以统计当前统计分析周期时间内各个容器的CPU资源用量，计算各个容器的CPU空闲率；根据各个容器的CPU空闲率判断容器的工作性质是CPU密集型还是非CPU密集型。

本实施例中，基于CFQ(Completely Fair Queuing，完全公平队列调度)按权重分配各个容器所能占用总体资源的百分比。

对于CPU密集型的容器，可以分配独立CPU资源，在cpuset.cpus中填写cgroup可使用的CPU编号，如0-2,16代表0、1、2和16这4个CPU；或者对其他容器可使用的CPU时间进行限制，保证CPU密集型容器的CPU使用时间。

图4示意性示出了根据本发明一个实施例的基于容器工作性质的资源调度装置的示意图，如图4所示，包括监控模块、判断模块、调度模块，其中，

所述监控模块，对宿主机中各容器进行监视；

所述判断模块，统计当前统计分析周期时间内各个容器的IO信息，判断容器的工作性质是IO密集型还是非IO密集型；

所述调度模块，将不同类型的容器放入不同的队列中，采用不同的调度策略。

具体地，

如图5所示，在本实施例中，所述监控模块包括：

扫描子模块，扫描宿主机内的容器，为每个容器配置对应的进程；

具体地，在宿主机内部启动本地监控程序，定时扫描宿主机内处于存活状态的主机，为其创建对应的进程，并将容器名称记录在容器列表中。通过上述步骤，创建多个进程，并行执行以获取各个容器的监控信息。

抽取子模块，各个进程同步抽取各自容器的状态信息；

各个进程抽取的状态信息包含但不限于以下几种：cpu状态信息、内存状态信息、网络状态信息以及磁盘状态信息，这几种信息是反映容器运行状态的关键指标信息。

Docker宿主机内具有一指定目录cgroup，cgroup目录下有一些文件是实时更新的，cpu状态信息和内存状态信息可通过读取这些文件记录的数据得到。

所述进程在Docker应用容器引擎的指定目录cgroup下抽取所述宿主机内部所有cpu的中断值；所述进程获取对应的容器所占用的cpu总中断值；以及根据所述宿主机的cpu共享策略，对所述容器所占用的cpu总中断值进行处理得到所述容器的cpu占用信息。

处理子模块，对各容器的状态信息进行处理，得到监控信息；

各个进程处理得到的监控信息包含但不限于以下几种：IO信息、CPU信息。

其中，IO信息的统计与监控如下，通过这些统计项统计、监控进程的IO情况。

blkio.reset_stats：重置统计信息，写入一个int值即可。

blkio.time：统计cgroup对设备的访问时间，按格式device_types:node_numbers milliseconds读取信息即可，以下类似。

blkio.io_serviced：统计cgroup对特定设备的IO操作(包括read、write、sync及async)次数，格式device_types:node_numbers operationnumber

blkio.sectors：统计cgroup对设备扇区访问次数，格式device_types:node_numbers sector_count

blkio.io_service_bytes：统计cgroup对特定设备IO操作(包括read、write、sync及async)的数据量，格式device_types:node_numbersoperation bytes

blkio.io_queued：统计cgroup的队列中对IO操作(包括read、write、sync及async)的请求次数，格式number operation

blkio.io_service_time：统计cgroup对特定设备的IO操作(包括read、write、sync及async)时间(单位为ns)，格式device_types:node_numbers operation time

blkio.io_merged：统计cgroup将BIOS请求合并到IO操作(包括read、write、sync及async)请求的次数，格式number operation

blkio.io_wait_time：统计cgroup在各设备中各类型IO操作(包括read、write、sync及async)在队列中的等待时间(单位ns)，格式device_types:node_numbers operation time。

其中，CPU信息的统计与监控如下，

cpuacct–CPU资源报告，这个子系统的配置是cpu子系统的补充，提供CPU资源用量的统计，时间单位都是纳秒。

1.cpuacct.usage：统计cgroup中所有task的cpu使用时长；

2.cpuacct.stat：统计cgroup中所有task的用户态和内核态分别使用cpu的时长；

3.cpuacct.usage_percpu：统计cgroup中所有task使用每个cpu的时长。

汇总子模块，将所有容器的监控信息汇总到数据队列中，每个容器的监控信息利用容器标识进行区分。

所述判断模块，统计当前统计分析周期时间内各个容器的IO信息，判断容器的工作性质是IO密集型还是非IO密集型；

本实施例中，基于CFQ(Completely Fair Queuing，完全公平队列调度)按权重分配各个容器所能占用总体资源的百分比。

所述判断模块，根据容器IO操作的中断频率判断所述容器的工作性质是否为IO密集型，将各容器的中断频率按照从高到低进行排列，将中断频率高于平均值的容器判断为IO密集型，将中断频率低于平均值的容器判断为非IO密集型。

所述调度模块，将不同类型的容器放入不同的队列中，采用不同的调度策略；进入下一个统计分析周期，将所述下一个统计分析周期作为新的统计分析周期，重新进行统计分析。

具体地，将IO密集型的容器放入IO密集型队列中，将非IO密集型的容器放入非IO密集型队列中；其中，非IO密集型队列采用默认调度算法；而IO密集型队列采用下列算法：

为了保持时间片的变化的稳定，减少性能颠簸，可以在容器连续几个统计分析周期中都判断为IO密集型的情况下才将其放入IO密集型队列中。可以使用老化算法来获取平滑后的IO操作终端频率。

具体地，可以将IO密集型容器的CPU时间片调整周期通过cpu.cfs_period_us设定为10ms，将非IO密集型的CPU时间片调整周期通过cpu.cfs_period_us设定为30ms。

这样，在一个统计分析周期内，IO密集型容器运行的总时间没有发生变化，但是调度的频率增加了，在保证公平的前提下，对IO请求的响应加快了。

但是，随着调度频率的增加，上下文切换的消耗也会增加，降低CPU处理效率，进而影响CPU密集型容器的性能。可以采用动态调度时间片的方法，根据根据IO密集型队列中各容器的实时CPU空闲率之和调度时间片。例如，将CPU空闲率之和从0％到100％映射到时间片的30ms到10ms区间内。CPU空闲率虽然在一段时间内相对稳定，但是在相邻的几个统计分析内会不停的变化，如果不停的改变时间片的大小也会造成性能颠簸。所以只有在连续几个统计分析周期CPU空闲率都处于某个范围的时候才会修改时间片大小。另一方面，在实际运行当中，这一统计分析周期之前一段时间的CPU空闲率也应该纳入考虑范围，这样可以减少CPU空闲率突变带来的误差。可以使用老化算法来获取平滑后的CPU空闲率。

可选的，所述装置还包括CPU监控模块，统计当前统计分析周期时间内各个容器的CPU资源用量，计算各个容器的CPU空闲率；根据各个容器的CPU空闲率判断容器的工作性质是CPU密集型还是非CPU密集型。

本实施例中，基于CFQ(Completely Fair Queuing，完全公平队列调度)按权重分配各个容器所能占用总体资源的百分比。

对于CPU密集型的容器，可以分配独立CPU资源，在cpuset.cpus中填写cgroup可使用的CPU编号，如0-2,16代表0、1、2和16这4个CPU；或者对其他容器可使用的CPU时间进行限制，保证CPU密集型容器的CPU使用时间。

本发明实施例所述基于容器工作性质的资源调度方法和装置，针对不同容器对IO操作和CPU计算需求上的差异，分别进行资源调度，在降低IO请求延迟的同时提供了足够的CPU时间用于处理IO请求，并且额外开销较小，具有良好的可适性。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的基于容器工作性质的资源调度装置的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

本文中所称的“一个实施例”、“实施例”或者“一个或者多个实施例”意味着，结合实施例描述的特定特征、结构或者特性包括在本发明的至少一个实施例中。此外，请注意，这里“在一个实施例中”的词语例子不一定全指同一个实施例。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下被实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

此外，还应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。因此，在不偏离所附权利要求书的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围，对本发明所做的公开是说明性的，而非限制性的，本发明的范围由所附权利要求书限定。

Claims (10)

1.一种基于容器工作性质的资源调度方法，其特征在于，包括：

对宿主机中各容器进行监视；

统计当前统计分析周期时间内各个容器的IO信息，判断容器的工作性质是IO密集型还是非IO密集型；

将不同类型的容器放入不同的队列中，采用不同的调度策略。

2.如权利要求1所述的基于容器工作性质的资源调度方法，其特征在于，所述对宿主机中各容器进行监视包括：

扫描宿主机内的容器，为每个容器配置对应的进程；

各个进程同步抽取各自容器的状态信息；

对各容器的状态信息进行处理，得到监控信息；

将所有容器的监控信息汇总到数据队列中，每个容器的监控信息利用容器标识进行区分。

3.如权利要求1所述的基于容器工作性质的资源调度方法，其特征在于，所述统计当前统计分析周期时间内各个容器的IO信息，判断容器的工作性质是IO密集型还是非IO密集型包括：

将各容器的中断频率按照从高到低进行排列，将中断频率高于平均值的容器判断为IO密集型，将中断频率低于平均值的容器判断为非IO密集型。

4.如权利要求1所述的基于容器工作性质的资源调度方法，其特征在于，所述将不同类型的容器放入不同的队列中，采用不同的调度策略包括：

将IO密集型的容器放入IO密集型队列中，将非IO密集型的容器放入非IO密集型队列中；

在连续几个统计分析周期中都判断为IO密集型容器的情况下才将其放入IO密集型队列中。

5.如权利要求1所述的基于容器工作性质的资源调度方法，其特征在于，所述将不同类型的容器放入不同的队列中，采用不同的调度策略包括：

降低IO密集型队列的CPU时间片调整周期；

保持非IO密集型队列的CPU时间片调整周期；

根据根据IO密集型队列中各容器的实时CPU空闲率之和动态调度时间片。

6.一种基于容器工作性质的资源调度装置，其特征在于，包括监控模块、判断模块、调度模块，其中，

所述监控模块，对宿主机中各容器进行监视；

所述判断模块，统计当前统计分析周期时间内各个容器的IO信息，判断容器的工作性质是IO密集型还是非IO密集型；

所述调度模块，将不同类型的容器放入不同的队列中，采用不同的调度策略。

7.如权利要求6所述的基于容器工作性质的资源调度装置，其特征在于，所述监控模块包括：

扫描子模块，扫描宿主机内的容器，为每个容器配置对应的进程；

抽取子模块，各个进程同步抽取各自容器的状态信息；

处理子模块，对各容器的状态信息进行处理，得到监控信息；

汇总子模块，将所有容器的监控信息汇总到数据队列中，每个容器的监控信息利用容器标识进行区分。

8.如权利要求6所述的基于容器工作性质的资源调度装置，其特征在于，

所述判断模块，将各容器的中断频率按照从高到低进行排列，将中断频率高于平均值的容器判断为IO密集型，将中断频率低于平均值的容器判断为非IO密集型。

9.如权利要求6所述的基于容器工作性质的资源调度装置，其特征在于，

所述调度模块，将IO密集型的容器放入IO密集型队列中，将非IO密集型的容器放入非IO密集型队列中；

所述调度模块在连续几个统计分析周期中都判断为IO密集型容器的情况下才将其放入IO密集型队列中。

10.如权利要求6所述的基于容器工作性质的资源调度装置，其特征在于，所述调度模块将不同类型的容器放入不同的队列中，采用不同的调度策略包括：

降低IO密集型队列的CPU时间片调整周期；

保持非IO密集型队列的CPU时间片调整周期；

根据根据IO密集型队列中各容器的实时CPU空闲率之和动态调度时间片。