CN113296923A - 内存合并方法、设备以及计算机可读介质 - Google Patents

Abstract

本申请提供了一种内存合并方案，该方案可以先确定运行实例的分组，然后对属于同一分组的运行实例的内存进行扫描及合并，由于同一分组的运行实例对应于同一应用程序，这些运行实例所运行的代码、运行时的参数以及代码运行逻辑几乎都是相同的，适合对其使用的内存进行合并，因此在扫描和合并时对计算资源的消耗更小，合并的效率更高。

Description

内存合并方法、设备以及计算机可读介质

技术领域

本申请涉及信息技术领域，尤其涉及一种内存合并方法、设备以及计算机可读介质。

背景技术

分布式集群环境下，同一物理节点上可能会存在应用程序的多个运行实例。例如在无服务器构架(Serverless)的场景下，为了加速应用程序的启动速度，需要集中部署应用程序的多个运行实例，从而构成一个热备实例的缓存池。在缓存池中，应用程序会存在多个运行实例，而且在随后的弹性扩容过程中，还会启动新的应用程序的运行实例加入到缓存池中。为了节约资源，尽可能对运行实例的内存进行合并。

KSM(Kernel Samepage Merging)是目前常用的一种内存合并技术，该技术会对标记运行实例的运行实例所使用的虚拟内存空间(VMA，Virtual Memory Area)并进行扫描及合并。KSM提供了两种内存合并模式，一种是在整个系统范围内，将所有内存页不做任何分组进行扫描及合并，另一种则是按照内存页所属的非一致性内存访问构架下的节点(NumaNode)，对属于同一节点下的内存页进行分别扫描及合并。这种扫描合并的策略更多的是从内存页的物理特性角度出发，并未考虑不同运行实例的内存是否适合进行合并。因此，若直接采用KSM的方式对应用程序的运行实例进行内存合并，则会导致额外的计算资源开销，使得合并的效率较低。

申请内容

本申请的一个目的是提供一种内存合并方法，用以解决内存合并效率不高的问题。

本申请实施例提供了一种内存合并方法，该方法包括：

确定运行实例的分组，其中，同一分组的运行实例对应于同一应用程序；

对属于同一分组的运行实例的内存进行扫描及合并。

本申请实施例还提供了一种内存合并设备，该设备包括：

分组模块，用于确定运行实例的分组，其中，同一分组的运行实例对应于同一应用程序；

扫描合并模块，用于对属于同一分组的运行实例的内存进行扫描及合并。

本申请的一些实施例还提供了一种计算设备，其中，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行前述的内存合并方法。

本申请的另一些实施例还提供了一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现所述的内存合并方法。

本申请实施例提供的一种内存合并方案中，可以先确定运行实例的分组，然后对属于同一分组的运行实例的内存进行扫描及合并，由于同一分组的运行实例对应于同一应用程序，这些运行实例所运行的代码、运行时的参数以及代码运行逻辑几乎都是相同的，适合对其使用的内存进行合并，因此在扫描和合并时对计算资源的消耗更小，合并的效率更高。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为本申请实施例提供的一种内存合并方法的处理流程图；

图2为本申请实施例中应用程序对应的进程分组示意图；

图3为本申请实施例中消费队列在某一时刻的状态示意图；

图4为本申请实施例中消费队列在另一时刻的状态示意图；

图5为本申请实施例中暂存队列和消费队列在某一时刻的状态示意图；

图6为本申请实施例提供的一种内存合并设备的结构示意图；

图7为本申请实施例提供的一种用于内存合并的计算设备的结构示意图；

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

在本申请一个典型的配置中，终端、服务网络的设备均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的装置或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本申请实施例提供了一种内存合并方法，该方法对运行实例的运行实例划分为不同的分组，并基于分组的粒度对内存进行扫描及合并。由于属于同一分组的运行实例对应于同一应用程序的不同运行实例，这些运行实例所运行的代码、运行时的参数以及代码运行逻辑几乎都是相同的，适合对其使用的内存进行合并，因此在扫描和合并时对计算资源的消耗更小，合并的效率更高。

在实际场景中，该方法的执行主体可以是用户设备、网络设备或者用户设备与网络设备通过网络相集成所构成的设备，此外也可以是运行于上述设备中的程序。所述用户设备包括但不限于计算机、手机、平板电脑等各类终端设备；所述网络设备包括但不限于如网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等实现。在此，云由基于云计算(Cloud Computing)的大量主机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟计算机。

图1示出了本申请实施例提供的一种内存合并方法的处理流程，至少包括以下的处理步骤：

步骤S101，确定运行实例的分组。划分这些分组的依据是运行实例是否属于同一应用程序，即同一分组的运行实例对应于同一应用程序。

步骤S102，对属于同一分组的运行实例的内存进行扫描及合并。由于相同应用程序的运行实例(如进程、容器等)所运行的代码、运行时的参数以及代码运行逻辑相似，因此他们在内存的使用上也相似的可能性更高。对同一分组的运行实例的内存之间进行合并的基础更好，在分组内对运行实例的内存进行扫描及合并时所需要的计算资源开销较小，效率更高。

此外，本申请实施例提供的内存合并方法也可以应用于无服务器(Serverless)场景，以用于对该场景中提供计算服务的服务集群进行内存合并。在无服务器场景中，应用程序的用户或者开发者无需关心在服务端的部署和运行，而可以由第三方提供的服务集群相应功能。这些服务集群用于为应用程序提供无服务器运行环境，使得应用程序对应的运行实例在服务集群中运行。因此，在服务集群中可能会运行部署应用程序的多个运行实例，为了尽可能的节约服务进群的内存，需要对服务集群进行内存合并。

本申请实施例提供的内存合并方法在应用于无服务器场景中时，可以先确定服务集群中运行实例的分组。其中，同一分组的运行实例对应于同一应用程序，所述服务集群用于为应用程序提供无服务器运行环境，以使所述应用程序对应的运行实例在所述服务集群中运行。而后，再对属于同一分组的运行实例的内存进行扫描及合并。

本申请的一些实施例在确定运行实例的分组时，可以获取运行实例的内核启动参数，然后根据所述内核启动参数确定所述运行实例的分组。例如，可以通过比较运行实例的内核启动参数，将内核启动参数相同的运行实例划分至同一分组。以进程为例，其内核启动参数可以由该进程的cmdline信息体现，通过对cmdline信息进行字符比较可以确定不同进程是否具有相同内核启动参数，从而确定所述运行实例的所属的分组。或者，也可以对cmdline信息进行哈希计算，通过比较计算获得哈希值来确定不同进程是否具有相同内核启动参数，从而确定所述运行实例的所属的分组。例如，对于10个进程而言，进程p1-p3具有相同的cmdline信息，进程p4-p6具有相同的cmdline信息，而进程p7-p10具有相同的cmdline信息，分别对这些进程的cmdline信息进行哈希计算之后，进程p1-p3对应的哈希值为hash1，进程p4-p6对应的哈希值为hash2，进程p7-p10对应的哈希值为hash3，由此可以这些进程划分为3个分组。由此，这些进程可以划分为如图2所示的分组，其中进程p1-p3的分组为arena1，进程p4-p6的分组为arena2，进程p7-p10的分组为arena3。然后，可以对每个分组下的进程所使用的内存分别进行扫描及合并，而不会对属于不同分组的几个进程的内存进行合并，例如不会将进程p4和进程p6的内存进行合并，由此可以针对性地在内存共享基础的运行实例之间进行内存合并，从而可以提高内存合并的效率。

在此，本领域技术人员应能理解上述确定运行实例的分组的具体方式仅为举例，其他现有的或今后可能出现的其它方式如可适用于本发明，也应包含在本发明保护范围以内，并在此以引用方式包含于此。例如，在某些情况下，可以同一应用程序对应的运行实例的内核启动参数可能存在一些区别，因此也可以根据实际场景的不同，参考内核启动参数整体的相似度或者是特定部分的相似度，将内核启动参数相似的运行实例划分至同一分组。

此外，还可以由用户自定义各个运行实例的分组，在运行实例创建后，根据用户的需要将一个运行实例直接分配至任意一个分组中。例如，在linux系统下，可以在sysfs节点下构件了一个arena hierarchy的数据结构，通过主动创建arena，作为分组，然后把进程等运行实例添加到该arena中，由此实现了用户通过自定义的方式主动为运行实例分配分组。

在实际场景中，例如KSM等内存合并技术在实现内存合并的过程中，会基于一定的周期对运行实例的内存进行扫描，然后对扫描过的内存空间进行合并。由此，若按照一定周期进行扫描会产生另一个问题，例如设备在一段时间内并没有向运行实例的内存中写入新的数据，此时内存中的内容并不会发生变化，没有合并内存的必要，因此也无需对其进行扫描，而周期性的扫描方式无法识别到此种情况，仍然会对运行实例的内存进行扫描，由此造成了不必要的计算开销。

为解决该问题，本申请的一些实施例中提供了一种采用了事件驱动方式来实现触发扫描，由此，在对属于同一分组的运行实例的内存进行扫描及合并时，是在产生合并事件后，对属于同一分组的相关运行实例的内存进行扫描及合并。其中，合并事件是触发运行实例进行内存合并的事件，以Linux系统为例，合并事件可以是由Madvise()方法产生的Merge事件，设备在调用Madvise()方法产生Merge事件之后，可以获取到该Merge事件，从而触发对相关运行实例的扫描及合并。

所述相关运行实例是指所述合并事件所属的运行实例，在实际场景中，一个运行实例会占用多个VMA，这些VMA会被标记从而产生合并事件，每标记一个VMA就产生一次合并事件。例如，一个进程p2属于分组arena1，使用了5个VMA，调用Madvise()方法对其中一个VMA标记会产生一个Merge事件，设备获取到该Merge事件之后，即可触发分组arena1中的相关进程进行内存的扫描和合并。在此场景中，相关进程即为p2，可以对其使用的内存进行扫描，然后可以将其与分组arena1中已扫描过的其它进程内存进行合并。

在运行实例较多时，在一定时间内产生的合并事件的数量也会较多，并且这些合并事件所属的运行实例也可能会属于不同的分组。在本申请的一些实施例中，可以维护一个消费队列，该消费队列用于存储待处理的合并事件，然后可以按照分组处理消费队列中的合并事件。

处理合并事件的过程为：在产生合并事件后，将所述合并事件加入消费队列，在所述消费队列中存在合并事件时，按照分组取出并处理所述消费队列中的合并事件。其中，处理合并事件即是指对相关运行实例的内存进行扫描及合并，而按照分组处理所述消费队列中合并事件则是对属于同一分组的相关运行实例的内存进行扫描及合并。

图3示出了消费队列在某一时刻的状态示意图，此时消费队列中包括了6个合并事件，其中合并事件e1、e4所属的运行实例属于arena1，合并事件e2、e3所属的运行实例属于arena2，合并事件e5、e6所属的运行实例属于arena3。由于此时消费队列中存在合并事件，因此会按照分组处理所述消费队列中合并事件，即每次取出一个分组的所有合并事件进行处理，处理这些合并事件的方式为对属于该分组的相关运行实例的内存进行扫描及合并。

以图3所示的消费队列为例，可以先取属于arena1的合并事件e1和e4，若合并事件e1属于进程p1，合并事件e4属于进程p2，处理合并事件e1和e4即为对进程p1和进程p2的内存进行扫描及合并。而在合并事件e1和e4从消费队列中取出并完成处理后，此时消费队列的状态如图4所示。然后，可以继续取出属于arena2的合并事件e2和e3或者是属于arena3的合并事件e5和e6继续处理，直至清空消费队列。

在此，本领域技术人员应能理解上述选取消费队列中的合并事件进行处理的顺序仅为举例，其他现有的或今后可能出现的其它方式如可适用于本发明，也应包含在本发明保护范围以内，并在此以引用方式包含于此。例如，可以按照分组ID的序号从小至的顺序从消费队列中取出合并事件并进行处理，即依次取出属于arena1、arena2、arena3、……的运行实例的合并事件，直至最后一个分组。或者，也可以根据合并事件的产生时间，优先处理产生时间较早的合并事件对应的分组。以图3所示的场景为例，若合并事件e2产生的时间最早，由于合并事件e2的所属的运行实例属于arena2，则可以先取出属于arena2的合并事件e2和e3，若合并事件e2属于进程p5，合并事件e3属于进程p5，处理合并事件e2和e3即为对进程p5和进程p6的内存进行扫描及合并。

在实际场景中，由于合并事件的处理需要一定的时间，因此在对消费队列中的合并事件进行处理的过程中，很可能会产生新的合并事件。若新产生的合并事件对应的分组与当前正在处理的合并事件的属于同一分组，可以不将该新产生的合并事件加入消费队列，而是直接与同组的合并事件一起进行处理，一起扫描所涉及的相关运行实例的内存并进行合并。例如，当前时刻取出了消费队列中的属于arena2的合并事件e2和e3，并正在扫描其对应的相关进程p5和进程p6，此时若产生了一个新的合并事件e7，该合并事件e7属于进程p4，同属于分组arena2，此时可以不将合并事件e7加入消费队列，而是直接与arena2的其它合并事件e2和e3一起进行处理。若此时若产生的新的一个合并事件e8属于进程p3，属于分组arena1，与正在处理的arena2并非同一分组，此时合并事件e8将加入消费队列，等待与同属于arena1的其它合并事件一起处理。

在本申请的另一些实施中，也可以维护两个队列，包括一暂存队列和一个消费队列。在产生合并事件后，可以将所述合并事件先加入暂存队列，并在满足预设条件时，将所述暂存队列中的合并事件加入消费队列。其中，所述预设条件可以根据实际场景的需求设定，例如可以是预设的时间间隔，由此可以每隔一定时间将暂存队列中的合并事件加入消费队列，或者也可以是队列中的合并事件数量达到预设值等。图5为两个队列的状态示意图，在产生合并事件后可以将产生合并事件先加入暂存队列，例如合并事件e1-e6在产生之后就会先加入暂存队列，由暂存队列记录这段时间内产生的所有合并事件，而后在达到预设时间间隔之后，可以将此时暂存队列中的合并事件加入到消费队列中，消费队列中的合并事件按照分组划分，并以分组为粒度进行处理。

本申请的一些实施例中，在产生合并事件后，可以确定所述合并事件的事件类型，而后根据所述合并事件的事件类型，对属于同一分组的相关运行实例的目标内存空间进行扫描及合并。其中，进行扫描的目标内存空间与事件类型相关，对于不同的事件类型，即使合并事件所标记内存空间相同，实际扫描的具体目标内存空间也会不相同。

所述事件类型包括第一事件类型和第二事件类型，若合并事件所属的运行实例首次有虚拟内存空间被扫描，则所述合并事件的事件类型为第一事件类型，对第一事件类型的合并事件的处理方式为：对属于同一分组的相关运行实例的所有虚拟内存空间进行扫描及合并。若合并事件所属的运行实例已有虚拟内存空间被扫描，则所述合并事件的事件类型为第二事件类型，对第二事件类型的合并事件的处理方式为：对属于同一分组的相关运行实例中合并事件所标记的虚拟内存空间进行扫描及合并。

例如，本实施例中第一事件类型可以记为RAW事件，而第二事件类型可以记为Mock事件。对于一个合并事件e1，该合并事件标记了进程p1中的一个VMA，若合并事件e1所标记的VMA为进程p1所使用的内存中首次被扫描的VMA，则该合并事件e1即为RAW事件，此时会对进程p1所使用的所有VMA进行一次全量的扫描，即RAW事件对应的目标内存空间为进程p1的所有VMA。对于另一个合并事件e2，该合并事件标记了进程p5中的一个VMA，若在合并事件e2之前，其所属的进程p5已经因之前的合并事件扫描过一次VMA，则此时仅需要扫描合并事件e2标记的VMA即可，即Mock事件对应的目标内存空间为进程p5中合并事件e2所标记的VMA。由此，由此可以根据不同的情况调整扫描范围，在不影响合并情况下减少不必要的扫描，解决计算资源开销，提升效率。

基于同一发明构思，本申请实施例中还提供了一种内存合并设备，所述设备对应的方法是前述实施例中的内存合并方法，并且其解决问题的原理与该方法相似。

本申请实施例提供的一种内存合并设备在实现内存合并时，对运行实例的运行实例划分为不同的分组，并基于分组的粒度对内存进行扫描及合并。由于属于同一分组的运行实例对应于同一应用程序的不同运行实例，这些运行实例所运行的代码、运行时的参数以及代码运行逻辑几乎都是相同的，适合对其使用的内存进行合并，因此在扫描和合并时对计算资源的消耗更小，合并的效率更高。

在实际场景中，该内存合并设备可以是用户设备、网络设备或者用户设备与网络设备通过网络相集成所构成的设备，此外也可以是运行于上述设备中的程序。所述用户设备包括但不限于计算机、手机、平板电脑等各类终端设备；所述网络设备包括但不限于如网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等实现。在此，云由基于云计算(Cloud Computing)的大量主机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟计算机。

图6示出了了本申请实施例提供的一种内存合并设备的结构，包括分组模块610和扫描合并模块620。其中，分组模块610用于确定运行实例的分组。划分这些分组的依据是运行实例是否属于同一应用程序，即同一分组的运行实例对应于同一应用程序。而扫描合并模块620用于对属于同一分组的运行实例的内存进行扫描及合并。由于相同应用程序的运行实例(如进程、容器等)所运行的代码、运行时的参数以及代码运行逻辑相似，因此他们在内存的使用上也相似的可能性更高。对同一分组的运行实例的内存之间进行合并的基础更好，在分组内对运行实例的内存进行扫描及合并时所需要的计算资源开销较小，效率更高。

此外，本申请实施例提供的内存合并设备也可以应用于无服务器(Serverless)场景，以用于对该场景中提供计算服务的服务集群进行内存合并。在无服务器场景中，应用程序的用户或者开发者无需关心在服务端的部署和运行，而可以由第三方提供的服务集群相应功能。这些服务集群用于为应用程序提供无服务器运行环境，使得应用程序对应的运行实例在服务集群中运行。因此，在服务集群中可能会运行部署应用程序的多个运行实例，为了尽可能的节约服务进群的内存，需要对服务集群进行内存合并。

本申请实施例提供的内存合并设备在应用于无服务器场景中时，可以由分组模块先确定服务集群中运行实例的分组。其中，同一分组的运行实例对应于同一应用程序，所述服务集群用于为应用程序提供无服务器运行环境，以使所述应用程序对应的运行实例在所述服务集群中运行。而后，再由扫描合并模块对属于同一分组的运行实例的内存进行扫描及合并。

本申请的一些实施例中，分组模块610在确定运行实例的分组时，可以获取运行实例的内核启动参数，然后根据所述内核启动参数确定所述运行实例的分组。例如，可以通过比较运行实例的内核启动参数，将内核启动参数相同的运行实例划分至同一分组。以进程为例，其内核启动参数可以由该进程的cmdline信息体现，通过对cmdline信息进行字符比较可以确定不同进程是否具有相同内核启动参数，从而确定所述运行实例的所属的分组。或者，也可以对cmdline信息进行哈希计算，通过比较计算获得哈希值来确定不同进程是否具有相同内核启动参数，从而确定所述运行实例的所属的分组。例如，对于10个进程而言，进程p1-p3具有相同的cmdline信息，进程p4-p6具有相同的cmdline信息，而进程p7-p10具有相同的cmdline信息，分别对这些进程的cmdline信息进行哈希计算之后，进程p1-p3对应的哈希值为hash1，进程p4-p6对应的哈希值为hash2，进程p7-p10对应的哈希值为hash3，由此可以这些进程划分为3个分组。由此，这些进程可以划分为如图2所示的分组，其中进程p1-p3的分组为arena1，进程p4-p6的分组为arena2，进程p7-p10的分组为arena3。然后，可以对每个分组下的进程所使用的内存分别进行扫描及合并，而不会对属于不同分组的几个进程的内存进行合并，例如不会将进程p4和进程p6的内存进行合并，由此可以针对性地在内存共享基础的运行实例之间进行内存合并，从而可以提高内存合并的效率。

在此，本领域技术人员应能理解上述确定运行实例的分组的具体方式仅为举例，其他现有的或今后可能出现的其它方式如可适用于本发明，也应包含在本发明保护范围以内，并在此以引用方式包含于此。例如，在某些情况下，可以同一应用程序对应的运行实例的内核启动参数可能存在一些区别，因此也可以根据实际场景的不同，参考内核启动参数整体的相似度或者是特定部分的相似度，将内核启动参数相似的运行实例划分至同一分组。

此外，还可以由用户自定义各个运行实例的分组，在运行实例创建后，分组模块610根据用户的需要将一个运行实例直接分配至任意一个分组中。例如，在linux系统下，可以在sysfs节点下构件了一个arena hierarchy的数据结构，通过主动创建arena，作为分组，然后把进程等运行实例添加到该arena中，由此实现了用户通过自定义的方式主动为运行实例分配分组。

在实际场景中，例如KSM等内存合并技术在实现内存合并的过程中，会基于一定的周期对运行实例的内存进行扫描，然后对扫描过的内存空间进行合并。由此，若按照一定周期进行扫描会产生另一个问题，例如设备在一段时间内并没有向运行实例的内存中写入新的数据，此时内存中的内容并不会发生变化，没有合并内存的必要，因此也无需对其进行扫描，而周期性的扫描方式无法识别到此种情况，仍然会对运行实例的内存进行扫描，由此造成了不必要的计算开销。

为解决该问题，本申请的一些实施例中提供了一种采用了事件驱动方式来实现触发扫描，由此，扫描合并模块620在对属于同一分组的运行实例的内存进行扫描及合并时，是在产生合并事件后，对属于同一分组的相关运行实例的内存进行扫描及合并。其中，合并事件是触发运行实例进行内存合并的事件，以Linux系统为例，合并事件可以是由Madvise()方法产生的Merge事件，设备在调用Madvise()方法产生Merge事件之后，可以获取到该Merge事件，从而触发对相关运行实例的扫描及合并。

所述相关运行实例是指所述合并事件所属的运行实例，在实际场景中，一个运行实例会占用多个VMA，这些VMA会被标记从而产生合并事件，每标记一个VMA就产生一次合并事件。例如，一个进程p2属于分组arena1，使用了5个VMA，调用Madvise()方法对其中一个VMA标记会产生一个Merge事件，设备获取到该Merge事件之后，即可触发分组arena1中的相关进程进行内存的扫描和合并。在此场景中，相关进程即为p2，可以对其使用的内存进行扫描，然后可以将其与分组arena1中已扫描过的其它进程内存进行合并。

在运行实例较多时，在一定时间内产生的合并事件的数量也会较多，并且这些合并事件所属的运行实例也可能会属于不同的分组。在本申请的一些实施例中，扫描合并模块620可以维护一个消费队列，该消费队列用于存储待处理的合并事件，然后可以按照分组处理消费队列中的合并事件。

处理合并事件的过程为：在产生合并事件后，将所述合并事件加入消费队列，在所述消费队列中存在合并事件时，按照分组取出并处理所述消费队列中的合并事件。其中，处理合并事件即是指对相关运行实例的内存进行扫描及合并，而按照分组处理所述消费队列中合并事件则是对属于同一分组的相关运行实例的内存进行扫描及合并。

图3示出了消费队列在某一时刻的状态示意图，此时消费队列中包括了6个合并事件，其中合并事件e1、e4所属的运行实例属于arena1，合并事件e2、e3所属的运行实例属于arena2，合并事件e5、e6所属的运行实例属于arena3。由于此时消费队列中存在合并事件，因此会按照分组处理所述消费队列中合并事件，即每次取出一个分组的所有合并事件进行处理，处理这些合并事件的方式为对属于该分组的相关运行实例的内存进行扫描及合并。

以图3所示的消费队列为例，可以先取属于arena1的合并事件e1和e4，若合并事件e1属于进程p1，合并事件e4属于进程p2，处理合并事件e1和e4即为对进程p1和进程p2的内存进行扫描及合并。而在合并事件e1和e4从消费队列中取出并完成处理后，此时消费队列的状态如图4所示。然后，可以继续取出属于arena2的合并事件e2和e3或者是属于arena3的合并事件e5和e6继续处理，直至清空消费队列。

在此，本领域技术人员应能理解上述选取消费队列中的合并事件进行处理的顺序仅为举例，其他现有的或今后可能出现的其它方式如可适用于本发明，也应包含在本发明保护范围以内，并在此以引用方式包含于此。例如，可以按照分组ID的序号从小至的顺序从消费队列中取出合并事件并进行处理，即依次取出属于arena1、arena2、arena3、……的运行实例的合并事件，直至最后一个分组。或者，也可以根据合并事件的产生时间，优先处理产生时间较早的合并事件对应的分组。以图3所示的场景为例，若合并事件e2产生的时间最早，由于合并事件e2的所属的运行实例属于arena2，则可以先取出属于arena2的合并事件e2和e3，若合并事件e2属于进程p5，合并事件e3属于进程p5，处理合并事件e2和e3即为对进程p5和进程p6的内存进行扫描及合并。

在实际场景中，由于合并事件的处理需要一定的时间，因此在对消费队列中的合并事件进行处理的过程中，很可能会产生新的合并事件。若新产生的合并事件对应的分组与当前正在处理的合并事件的属于同一分组，可以不将该新产生的合并事件加入消费队列，而是直接与同组的合并事件一起进行处理，一起扫描所涉及的相关运行实例的内存并进行合并。例如，当前时刻取出了消费队列中的属于arena2的合并事件e2和e3，并正在扫描其对应的相关进程p5和进程p6，此时若产生了一个新的合并事件e7，该合并事件e7属于进程p4，同属于分组arena2，此时可以不将合并事件e7加入消费队列，而是直接与arena2的其它合并事件e2和e3一起进行处理。若此时若产生的新的一个合并事件e8属于进程p3，属于分组arena1，与正在处理的arena2并非同一分组，此时合并事件e8将加入消费队列，等待与同属于arena1的其它合并事件一起处理。

在本申请的另一些实施中，扫描合并模块620也可以维护两个队列，包括一暂存队列和一个消费队列。在产生合并事件后，可以将所述合并事件先加入暂存队列，并在满足预设条件时，将所述暂存队列中的合并事件加入消费队列。其中，所述预设条件可以根据实际场景的需求设定，例如可以是预设的时间间隔，由此可以每隔一定时间将暂存队列中的合并事件加入消费队列，或者也可以是队列中的合并事件数量达到预设值等。图5示出了两个队列的状态示意图，在产生合并事件后可以将产生合并事件先加入暂存队列，例如合并事件e1-e6在产生之后就会先加入暂存队列，由暂存队列记录这段时间内产生的所有合并事件，而后在达到预设时间间隔之后，可以将此时暂存队列中的合并事件加入到消费队列中，消费队列中的合并事件按照分组划分，并以分组为粒度进行处理。

本申请的一些实施例中，扫描合并模块620在产生合并事件后，可以确定所述合并事件的事件类型，而后根据所述合并事件的事件类型，对属于同一分组的相关运行实例的目标内存空间进行扫描及合并。其中，进行扫描的目标内存空间与事件类型相关，对于不同的事件类型，即使合并事件所标记内存空间相同，实际扫描的具体目标内存空间也会不相同。

所述事件类型包括第一事件类型和第二事件类型，若合并事件所属的运行实例首次有虚拟内存空间被扫描，则所述合并事件的事件类型为第一事件类型，对第一事件类型的合并事件的处理方式为：对属于同一分组的相关运行实例的所有虚拟内存空间进行扫描及合并。若合并事件所属的运行实例已有虚拟内存空间被扫描，则所述合并事件的事件类型为第二事件类型，对第二事件类型的合并事件的处理方式为：对属于同一分组的相关运行实例中合并事件所标记的虚拟内存空间进行扫描及合并。

例如，本实施例中第一事件类型可以记为RAW事件，而第二事件类型可以记为Mock事件。对于一个合并事件e1，该合并事件标记了进程p1中的一个VMA，若合并事件e1所标记的VMA为进程p1所使用的内存中首次被扫描的VMA，则该合并事件e1即为RAW事件，此时会对进程p1所使用的所有VMA进行一次全量的扫描，即RAW事件对应的目标内存空间为进程p1的所有VMA。对于另一个合并事件e2，该合并事件标记了进程p5中的一个VMA，若在合并事件e2之前，其所属的进程p5已经因之前的合并事件扫描过一次VMA，则此时仅需要扫描合并事件e2标记的VMA即可，即Mock事件对应的目标内存空间为进程p5中合并事件e2所标记的VMA。由此，由此可以根据不同的情况调整扫描范围，在不影响合并情况下减少不必要的扫描，解决计算资源开销，提升效率。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一些实施例包括一个如图7所示的计算设备，该设备包括存储有计算机可读指令的一个或多个存储器710和用于执行计算机可读指令的处理器720，其中，当该计算机可读指令被该处理器执行时，使得所述设备执行基于前述本申请的多个实施例的方法和/或技术方案。

此外，本申请的一些实施例还提供了一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现前述本申请的多个实施例的方法和/或技术方案。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一些实施例中，本申请的软件程序可以通过处理器执行以实现上文步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (18)

1.一种内存合并方法，其中，该方法包括：

确定运行实例的分组，其中，同一分组的运行实例对应于同一应用程序；

对属于同一分组的运行实例的内存进行扫描及合并。

2.根据权利要求1所述的方法，其中，确定运行实例的分组，包括：

获取运行实例的内核启动参数；

根据所述内核启动参数，确定所述运行实例的分组。

3.根据权利要求2所述的方法，其中，根据所述内核启动参数，确定所述运行实例的分组，包括：

比较运行实例的内核启动参数，将内核启动参数相同的运行实例划分至同一分组。

4.根据权利要求1所述的方法，其中，对属于同一分组的运行实例的内存进行扫描及合并，包括：

在产生合并事件后，对属于同一分组的相关运行实例的内存进行扫描及合并，其中，相关运行实例为所述合并事件所属的运行实例。

5.根据权利要求4所述的方法，其中，在产生合并事件后，对属于同一分组的相关运行实例的内存进行扫描及合并，包括：

在产生合并事件后，将所述合并事件加入消费队列；

在所述消费队列中存在合并事件时，按照分组取出并处理所述消费队列中的合并事件，其中，按照分组处理所述消费队列中合并事件为对属于同一分组的相关运行实例的内存进行扫描及合并。

6.根据权利要求5所述的方法，其中，在产生合并事件后，将所述合并事件加入消费队列，包括：

在产生第一合并事件后，将所述合并事件加入暂存队列；

在满足预设条件时，将所述暂存队列中的合并事件加入消费队列。

7.根据权利要求4所述的方法，其中，在产生合并事件后，对属于同一分组的相关运行实例的内存进行扫描及合并，包括：

在产生合并事件后，确定所述合并事件的事件类型；

根据所述合并事件的事件类型，对属于同一分组的相关运行实例的目标内存空间进行扫描及合并。

8.根据权利要求7所述的方法，其中，所述事件类型包括第一事件类型和第二事件类型，若合并事件所属的运行实例首次有虚拟内存空间被扫描，则所述合并事件的事件类型为第一事件类型，若合并事件所属的运行实例已有虚拟内存空间被扫描，则所述合并事件的事件类型为第二事件类型；

根据所述合并事件的事件类型，对属于同一分组的相关运行实例的目标内存空间进行扫描及合并，包括：

若所述合并事件的事件类型为第一事件类型，对属于同一分组的相关运行实例的所有虚拟内存空间进行扫描及合并；

若所述合并事件的事件类型为第二事件类型，对属于同一分组的相关运行实例中合并事件所标记的虚拟内存空间进行扫描及合并。

9.一种内存合并方法，其中，该方法包括：

确定服务集群中运行实例的分组，其中，同一分组的运行实例对应于同一应用程序，所述服务集群用于为应用程序提供无服务器运行环境，以使所述应用程序对应的运行实例在所述服务集群中运行；

对属于同一分组的运行实例的内存进行扫描及合并。

10.一种内存合并设备，其中，该设备包括：

分组模块，用于确定运行实例的分组，其中，同一分组的运行实例对应于同一应用程序；

扫描合并模块，用于对属于同一分组的运行实例的内存进行扫描及合并。

11.根据权利要求10所述的设备，其中，所述分组模块，用于获取运行实例的内核启动参数，并根据所述内核启动参数，确定所述运行实例的分组。

12.根据权利要求10所述的设备，其中，所述扫描合并模块，用于在产生合并事件后，对属于同一分组的相关运行实例的内存进行扫描及合并，其中，相关运行实例为所述合并事件所属的运行实例。

13.根据权利要求12所述的设备，其中，所述扫描合并模块，用于在产生合并事件后，将所述合并事件加入消费队列，在所述消费队列中存在合并事件时，按照分组取出并处理所述消费队列中的合并事件，其中，按照分组处理所述消费队列中合并事件为对属于同一分组的相关运行实例的内存进行扫描及合并。

14.根据权利要求12所述的设备，其中，所述扫描合并模块，用于在产生合并事件后，确定所述合并事件的事件类型；以及根据所述合并事件的事件类型，对属于同一分组的相关运行实例的目标内存空间进行扫描及合并。

15.根据权利要求14所述的设备，其中，所述事件类型包括第一事件类型和第二事件类型，若合并事件所属的运行实例首次有虚拟内存空间被扫描，则所述合并事件的事件类型为第一事件类型，若合并事件所属的运行实例已有虚拟内存空间被扫描，则所述合并事件的事件类型为第二事件类型；

所述扫描合并模块，用于在所述合并事件的事件类型为第一事件类型时，对属于同一分组的相关运行实例的所有虚拟内存空间进行扫描及合并；以及在所述合并事件的事件类型为第二事件类型时，对属于同一分组的相关运行实例中合并事件所标记的虚拟内存空间进行扫描及合并。

16.一种内存合并设备，其中，该设备包括：

分组模块，用于确定服务集群中运行实例的分组，其中，同一分组的运行实例对应于同一应用程序，所述服务集群用于为应用程序提供无服务器运行环境，以使所述应用程序对应的运行实例在所述服务集群中运行；

扫描合并模块，用于对属于同一分组的运行实例的内存进行扫描及合并。

17.一种计算设备，其中，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行权利要求1至9中任一项所述的方法。

18.一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现如权利要求1至9中任一项所述的方法。

Images