基于动态负载的系统资源分配方法和系统与流程

1.本技术涉及云计算技术领域，尤其涉及一种基于动态负载的系统资源分配方法和系统。


背景技术：

2.那么对于一个应用服务器而言，同一时间可能会有很多人来同时使用，这就会造成资源的抢占问题，对于操作系统而言，对于多个进程的资源分配更多的是依赖于操作系统的内部实现，然而这会导致一些很严重的问题，那就是资源的分配不合理，进而会造成用户的操作体验下降。现有技术中，一般是通过虚拟机或者通过容器方式来进行资源限制，这两种方式都有自己的使用场景，也都有各自的问题。
3.工业设计仿真云可以为用户提供基于云端应用交付的使用场景，即工程师可以使用saas化的设计仿真软件来进行工作，能够大大提高工作效率，而其在实际应用中，首先需要保证用户的操作体验,也就是要快、要流畅。而通过虚拟机的方式来进行软件的部署，会有很大的性能损耗，同时用户体验比较差。另外，因为容器方式不支持工业设计仿真云的应用方式，所以也不能通过容器的方式来进行软件的部署，所以现有技术中并没有行之有效的用于针对云服务尤其是工业设计仿真云的系统资源分配方法。


技术实现要素：

4.本技术提供一种基于动态负载的系统资源分配方法，以解决现有技术中，针对云服务或工业设计仿真云领域，没有有效的系统资源分配方法，导致资源分配不合理，用户体验差的问题。
5.本技术的上述目的是通过以下技术方案实现的：
6.第一方面，本技术实施例提供一种基于动态负载的系统资源分配方法，包括：
7.采集预设应用运行特征，构建当前应用的运行特征库；其中所述运行特征包括所述预设应用运行时耗费的cpu和内存资源；
8.动态采集当前服务器的负载信息；
9.根据所述运行特征库和所述负载信息，基于预设资源分配策略进行资源分配。进一步的，所述采集预设应用运行特征，包括：
10.基于用户预设时间内的使用需求和工作需要进行统计；
11.基于统计结果，实时获取当前应用进程的资源占比。
12.进一步的，所述负载信息包括：
13.当前用户数、系统当前可用内存、系统当前可用cpu平均曲线和系统当前时段峰值信息。
14.进一步的，所述预设资源分配策略包括自动分配策略和人工手动设定分配资源。
15.进一步的，所述自动分配策略包括：
16.基于所述运行特征库和所述负载信息通过分配器进行资源分配。
17.进一步的，所述基于所述运行特征库和所述负载信息通过分配器进行资源分配，包括：
18.将系统资源分为基础运行池、扩展池和保留池；
19.通过分配器先在所述基础运行池中为应用软件分配资源；
20.扩展池用于基于用户使用情况动态切分后为用户分配资源。
21.进一步的，其特征在于，所述人工手动设定分配资源包括：
22.人工手动针对特定预设应用进行资源分配指定；
23.通过分配器基于所述资源分配指定进行资源分配。
24.进一步的，还包括：
25.在所述基础运行池和所述扩展池均分配完毕后，基于当前运行应用，检索得到运行特征为重载的应用；
26.基于检索结果再次进行资源的分配。
27.进一步的，还包括：
28.通过调用windows的api进行进程资源的限定。
29.第二方面，本技术实施例提供一种基于动态负载的系统资源分配系统，包括：
30.第一获取模块，用于采集预设应用运行特征，构建当前应用的运行特征库；其中所述运行特征包括所述预设应用运行时耗费的cpu和内存资源；
31.第二获取模块，用于动态采集当前服务器的负载信息；
32.分配模块，用于根据所述运行特征库和所述负载信息，基于预设资源分配策略进行资源分配。
33.本技术的实施例提供的技术方案可以包括以下有益效果：
34.本技术的实施例提供的技术方案中，首先采集预设应用运行特征，构建当前应用的运行特征库；其中所述运行特征包括所述预设应用运行时耗费的cpu和内存资源；然后动态采集当前服务器的负载信息；最后基于所述运行特征库和所述负载信息，通过预设资源分配策略进行资源分配。如此，通过基于应用运行特征和负载信息，对资源进行分配，使资源分配更加合理，从而提高资源利用率，提高用户体验。
35.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本技术。
附图说明
36.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。
37.图1为本技术实施例提供的一种基于动态负载的系统资源分配方法的流程示意图；
38.图2为本技术实施例提供的一种基于动态负载的系统资源分配系统的结构示意图。
具体实施方式
39.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及
附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本技术相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本技术的一些方面相一致的装置和方法的例子。
40.在服务器或者大型计算机集群中，往往需要运行大量作业和应用，为保证这些作业和应用的进程之间互不干扰，人们尝试使用了资源隔离技术来为各个应用进程划定固定的资源空间，使得进程运行范围被限制在有限空间内，由此就保证了进程的运行不受其他进程的干扰。这其中被广泛使用的技术包括虚拟机技术和容器技术，这两种技术都属于虚拟化的范畴，但是实现的机理和运行效率却相差悬殊。
41.虚拟化技术分为主机级虚拟化和容器级虚拟化，分别对应虚拟机和容器，而主机级虚拟化又分为两种，具体分类情况大致列举如下：
42.首先对于主机级虚拟化，包括type1：直接在硬件平台(host machine)上装一个虚拟机管理器(virtual machine monitor，缩写为vmm，eg.hypervisor)，在此之上安装使用虚拟机(guest machine)。type2：硬件平台先安装主机操作系统(host os)，在此之上安装vmm(虚拟机管理器)，在这个软件之上创建使用虚拟机。eg.vm，workstation，virtual box。
43.传统的虚拟化方式的的确确可以在一组硬件平台之上实现跨系统环境的隔离调式等，也可以实现资源的充分利用，但是其带来的资源开销也不容忽视。传统主机级虚拟化，存在两层调度和资源分配。在第一级内核层，要实现内存虚拟化、cpu调度、i/o管理等；而在第二级内核层，即在宿主机内核管理的抽象层，还需再次调度。这套机制的运行将严重浪费时间，造成额外开销。很多时候，创建虚拟机的目的是运行有限的几个生产进程，而为此付出较大的代价，显得得不偿失。因此减少中间层，减少开销，提升效率尤为重要。
44.由此，人们想到抽离虚拟机中进程之下的内核层，其实质也就变成了容器技术。容器技术的目的在于：在系统内核之上，提供隔离的用户空间，使得用户运行进程不受其他进程干扰，进程运行所能看到的边界就是自己所在用户空间的边界。运行虚拟机的目的不只是为了运行进程，还有隔离等。所以，虽然抽离了内核层，但是隔离效果依然要存在，那么接下来我们就来了解一下容器技术中的隔离是如何实现的。
45.这里，首先来介绍linux中的namespace机制，namespace(命名空间)是linux提供的一种内核级别环境隔离的方法。其中应该了解linux系统中的chroot命令，chroot，即change root directory，通过修改分目录把用户jail到一个特定目录下。chroot提供了一种简单的隔离模式：chroot内部的文件系统无法访问外部的内容。而linux namespace在此基础之上，又提供了对uts、mount、ipc、pid、user和net等的隔离机制。
46.具体的，uts namespace：uts，即unix time-sharing system namespace，提供了主机名和域名的隔离，使得子进程有独立的主机名和域名(hostname)。不难理解，运行在同一主机上的多个容器，从用户角度来看，着多个容器就是多台可以独立使用的主机，那么从系统角度来看，要对这多个让其进行区分隔离，那他们就必须拥有自己独一无二的名字，因此linux namespace提供了对主机名、域名的隔离。默认情况下，容器的hostname就是它的短id，用户也可以在容器启动时设定一个名字，也通过-h或
–
hostname参数设置。
47.mount namespace：为进程提供独立的文件系统试图，让容器看上去拥有整个文件系统，即拥有/、/bin、/sbin、/etc等目录。简单来讲，mount namespace就是隔离文件系统的挂载点，这样进程就只能看到自己的mount namespace中的文件系统挂载点。因此，在容器
中对文件系统进行的相关操作，并不能影响到host和其他容器的文件系统。
48.ipc namespace：ipc，即inter-process communication，是unix/linux中进程间通信的一种方式，ipc有共享内存、信号量、消息队列等方法。每个用户空间都有自己的ipc，所以，为了保证同一用户空间进程之间可以通信而跨用户空间的进程之间无法通信，也需要对ipc进行隔离。ipc需要有一个全局的id，既然是全局的，那么就意味着namespace需要对这个id进行隔离，不能让别的namespace的进程看到。
49.pid namespace：pid，即process id。在所有用户空间中，每个进程都应从属于一个进程，因为每一个进程都由其父进程创建，否则，该进程则为init进程。一个系统运行要有两棵树的存在，即进程树和文件系统树，既然对于当前用户空间，若让其以为自身为当前系统中唯一一个用户空间，那么其中的进程就必须明确自己从属于某一init进程或者自己就是init进程。但一个实际的系统中，只存在一个init进程，于是为每一个用户空间创建的所谓的“init”进程，对于该用户空间来说是一个特殊的进程，但对于系统来说，并非init进程。当该特殊进程结束时，那么该用户空间也将消失。照此理解，namespace也对pid进行了隔离。
50.user namespace：所有的用户进程，都应隶属于某一真实用户，不同应用空间可能存在用户id相同，而用户名不同的情况。一个系统只应存在一个root用户，而每一个用户空间也需要一个“root”用户，这也就意味着对于用户空间而言的“root”用户对于系统而言只是一个普通用户，而对于所处用户空间而言，可以将该用户id伪装为id为0的用户，该用户只能在自身用户空间之内为所欲为。照此理解，namespace亦实现了对用户的隔离。
51.network namespace：对于network的隔离，即让容器拥有自己独立的网卡、ip、路由等资源，因而，两个容器既可以通过网络通信。
52.在主机内核级别，所有的资源都独立只有一组，原本只支持单个用户空间的运行，后来，因为有这种运行jail/vserver的需要，就在内核级别将这些资源进行了虚拟化，即将资源切分为多个互相隔离的环境(namespace)，在同一内核创建多个名称空间，每个名称空间有自己独立的主机名。所有容器机制的实现，linux内核已经在内核级通过一个namespace的机制对以上6中需要隔离的资源原生支持，可以直接通过系统调用向外输出。容器级虚拟化技术，可以在总体用户空间上实现资源按比例分配，也可以在单一用户空间上实现固定数量的资源(eg.num.of cores)绑定，而这一操作是借助cgroups(control groups，控制组)实现的。控制组就是一组按照某种标准划分的进程。cgroups中的资源控制都是以控制组为单位实现。一个进程可以加入到某个控制组，也从一个进程组迁移到另一个控制组。一个进程组的进程可以使用cgroups以控制组为单位分配的资源，同时受到cgroups以控制组为单位设定的限制。并不适用于本技术提供的云服务以及工业设计仿真云服务领域中。
53.为了解决上述问题，本技术提供一种基于动态负载的系统资源分配方法，以对云服务尤其是工业设计仿真云化场景的资源进行分配，从而实现合理分配系统资源，提高系统资源利用率，提升用户体验。具体实现方案通过以下实施例进行详细说明。
54.实施例
55.参照图1，图1为本技术实施例提供的一种基于动态负载的系统资源分配方法，如图1所示，该方法至少包括以下步骤：
56.s101、采集预设应用运行特征，构建当前应用的运行特征库；其中所述运行特征包括所述预设应用运行时耗费的cpu和内存资源。
57.在本技术实施例中，采集预设应用运行特征包括：基于用户预设时间内的使用需求和工作需要进行统计；基于统计结果，实时获取当前应用进程的资源占比。
58.具体的，通过执行应用运行特征采集来将不同应用在运行时所耗费的cpu和内存资源进行统计，通过平台或者拟合手段来形成当前应用的运行特征库。需要说明的是，该库的特征信息是一直在采集的，即在应用运行中，是持续实时采集的，而且会根据用户的最近使用需求以及工作需求来统计，不是一成不变的。在实际应用中，采集的方式主要是获取当前应用进程的资源占比。
59.s102、动态采集当前服务器的负载信息。
60.具体的，服务器的负载主要是由多个应用并发运行造成的，动态采集当前服务器的负载情况，即采集的负载信息大致包括当前用户数、系统当前可用内存、系统当前可用cpu平均曲线、系统当前时段峰值信息等。
61.s103、根据所述运行特征库和所述负载信息，基于预设资源分配策略进行资源分配。
62.在实际应用中，本技术实施例提供的基于动态负载的系统资源分配方法中，预设资源分配策略包括自动分配策略和人工手动设定分配资源。
63.具体的，自动分配策略主要是分配器根据应用特征以及当前运行负载进行自动分配。我们将资源分为三个池子，几个是基础运行池、一个是扩展池、最后一个是保留池。当用户连接到系统之后，我们会根据应用特征给用户在基础运行池分配一个软件基础可用状态下的资源，保障该应用的相应，扩展池主要根据系统负责来进行动态切分，如果当前只有一个用户，则会将所有资源分配给该用户进程。
64.另外，当所有基础运行池以及扩展池都分配完毕之后，系统会根据当前运行应用中，检索出运行特征是重载的应用，再次进行资源的分配，已保障仿真等应用的资源占用。
65.另一方面，在本技术实施例提供的基于动态负载的系统资源分配方法中，资源分配策略还包括人工手动设定分配资源，具体的，可以支持人工手动设定分配资源，人工手动分配策略方式主要是可以对特定应用进行资源分配指定，分配器会直接按照人工设定值进行资源分配。通过增加人工手动设定分配资源，对特定应用进行特殊处理，从而提高资源分配过程的灵活性和针对性，使系统资源分配更加合理。
66.需要说明的是，本技术实施例提供的基于动态负载的系统资源分配方法中，在实现手段上，为通过调用windows的api来进行进程的资源限定。
67.本技术的实施例提供的技术方案中，软件都是直接部署在操作系统中，并未采用虚拟化方式，并且能够根据应用特征而非通用化的资源限定手段来进行资源的动态切分。通过上述的技术方案，本发明可以解决在操作系统上能够根据进程特征以及并发人数来进行资源动态切分，实现了能够在操作系统中根据配额限定进程所占用的cpu和内存资源、能够根据态势动态改变进程锁占用的cpu和内存资源、能够将进程绑定到特定核心进行工作以及能够采集应用进程的资源占用特征，从而动态调配进程资源占用。实现使资源分配更加合理，提高了资源分配效率，提升了用户体验。
68.此外，基于相同的发明构思，对应于上述的基于动态负载的系统资源分配方法，本
申请实施例还提供一种基于动态负载的系统资源分配系统，参照图2，图2为本技术实施例提供的一种基于动态负载的系统资源分配系统的结构示意图。如图2所示，该系统至少包括以下结构：
69.第一获取模块21，用于采集预设应用运行特征，构建当前应用的运行特征库；其中所述运行特征包括所述预设应用运行时耗费的cpu和内存资源。
70.第二获取模块22，用于动态采集当前服务器的负载信息。
71.分配模块23，用于根据所述运行特征库和所述负载信息，基于预设资源分配策略进行资源分配。
72.可以理解的是，上述各实施例中相同或相似部分可以相互参考，在一些实施例中未详细说明的内容可以参见其他实施例中相同或相似的内容。
73.需要说明的是，在本技术的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本技术的描述中，除非另有说明，“多个”的含义是指至少两个。
74.流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本技术的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本技术的实施例所属技术领域的技术人员所理解。
75.应当理解，本技术的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(pga)，现场可编程门阵列(fpga)等。
76.本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
77.此外，在本技术各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。
78.上述提到的存储介质可以是只读存储器，磁盘或光盘等。
79.在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本技术的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
80.尽管上面已经示出和描述了本技术的实施例，可以理解的是，上述实施例是示例
性的，不能理解为对本技术的限制，本领域的普通技术人员在本技术的范围内可以对上述实施例进行变化、修改、替换和变型。