CN109324893B - 分配内存的方法和装置 - Google Patents
分配内存的方法和装置 Download PDFInfo
- Publication number
- CN109324893B CN109324893B CN201810888058.2A CN201810888058A CN109324893B CN 109324893 B CN109324893 B CN 109324893B CN 201810888058 A CN201810888058 A CN 201810888058A CN 109324893 B CN109324893 B CN 109324893B
- Authority
- CN
- China
- Prior art keywords
- memory
- function
- balloon
- size
- running
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
Abstract
本申请提供了一种分配内存的方法。该方法包括:生成描述用于搭载虚拟机或容器的运行载体的镜像文件;基于该镜像文件部署该运行载体中部署供该运行载体使用的内存气球;随后,根据用户输入的运行函数的请求确定运行该函数需要的内存大小,从而,基于该内存气球分配供该函数运行的内存。这样,根据函数运行中需要的内存大小,使用内存气球按需分配内存,有效地提高了内存资源配置的灵活性。
Description
技术领域
本申请涉及存储领域,更具体地,涉及存储领域中分配内存的方法和装置。
背景技术
目前,无服务器(serverless)计算技术,是新一代云服务和开发架构的实现,函数即服务(functions as a service,FaaS)是无服务器计算技术的一种业务类型,其中,函数服务(function stage)是无服务器计算技术的核心技术,支持多种语言的函数的在线编辑和运行,可以使得同一个宿主机中运行多个函数。
在无服务计算技术中,占用的内存资源少、函数启动快是两个关键指标。为了提高函数服务技术的上述性能,目前提供了一种技术。在该技术中,将用于描述运行载体的相关数据转存至镜像文件,基于还原的镜像文件运行函数。但是,由于运行函数的运行载体中的进程的内存是由用户指定的,因此,需要基于进程占用的多种内存大小制作多种镜像文件,大大降低了内存资源配置的灵活性,例如,若新增加一种内存大小,还需要重新制作一种镜像文件。
因此,需要提供一种技术,有助于提高内存资源配置的灵活性。
发明内容
本申请提供一种分配内存的方法和装置,能有有效地提高内存资源配置的灵活性。
第一方面,提供了一种分配内存的方法,所述方法包括:
生成用于描述运行载体的镜像文件,所述运行载体为用于搭载运行环境的虚拟机或容器;
使用所述镜像文件部署所述运行载体,包括部署供所述运行载体使用的内存气球;
接收运行函数的请求;
根据所述运行函数的请求,使用所述内存气球分配供所述函数运行的内存。
因此,本申请实施例提供的分配内存的方法,仅需要制作一个用于描述运行载体(例如,虚拟机或容器)的镜像文件,在使用该镜像文件部署该运行载体过程中,通过部署供该运行载体使用的内存气球,使得设备可以基于函数运行需要的内存大小,使用该内存气球动态地分配供该函数运行的内存,以满足该函数的运行,可以有效地提高运行载体中内存资源配置的灵活性。
相比于现有技术制作多个镜像文件的方案,本申请实施例仅需要制作一个镜像文件就可以运行函数,大大节省了磁盘存储空间。
在一种可能的实现方式中,所述方法还包括:
根据运行所述函数的内存大小的变化,使用所述内存气球调整为所述函数分配的内存。
因此,本申请实施例提供的分配内存的方法,通过基于函数在运行过程需要的内存的内存大小的变化,使用内存气球动态调整为该函数分配的内存,可以有效地保证函数的正常运行。
在一种可能的实现方式中,所述根据运行所述函数的内存大小的变化,使用所述内存气球调整为所述函数分配的内存,包括:
若当前运行所述函数需要的内存大小大于先前运行所述函数所需的内存大小,则使用所述内存气球增加为所述函数分配的内存的内存大小;或,
若当前运行所述函数需要的内存大小小于先前运行所述函数所需的内存大小,则利用所述函数使用的内存生成内存气球。
在一种可能的实现方式中,所述使用所述内存气球分配供所述函数运行的内存,包括:
根据所述运行函数的请求,确定运行所述函数的内存大小;
使用所述内存气球分配确定的内存大小的内存。
在一种可能的实现方式中,所述内存气球中的内存属于堆内存中的老年代区域中的内存。
因此,通过堆内存中的老生代区域中获取内存气球,可以有效地减少释放出的内存被回收利用的可能性,便于方案的可执行性。
第二方面,提供了一种分配内存的装置,用于执行第一方面或第一方面的任意可能的实现方式中的方法。具体地,该装置包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的单元。
第三方面,提供了一种分配内存的设备,所述设备包括处理器和存储器;所述存储器用于存储计算机指令。当所述设备运行时,所述处理器执行所述存储器存储的所述计算机指令,以使所述设备执行第一方面或第一方面的任意可能的实现方式中的各个过程。
第四方面,提供了一种计算机存储介质,所述计算机存储介质包括计算机指令,当计算机的处理器执行所述计算机指令时,所述计算机执行上述第一方面或第一方面的任意可能的实现方式中的各个过程。
第五方面,提供了一种芯片,所述芯片包括处理器和存储器,所述处理器用于执行所述存储器存储的指令,当所述指令被执行时,所述处理器可以实现第一方面或第一方面的任意可能的实现方式中的各个过程。
附图说明
图1是适用于本申请实施例的系统架构的示意图。
图2是现有技术中制作镜像文件和选择镜像文件的过程的示意图。
图3是本申请实施例提供的分配内存的方法的示意性流程图。
图4是本申请实施例提供使用内存气球分配供函数运行的内存的过程的示意图。
图5是本申请实施例提供的调用函数的方法的示意性流程图。
图6是本申请实施例提供的使用内存气球中动态调整为函数分配的内存的过程的示意图。
图7是本申请实施例提供的另一分配内存的方法的示意性流程图。
图8是本申请实施例提供的不同进程间共享内存的示意图。
图9是本申请实施例提供的分配内存的装置的示意性框图。
图10是本申请实施例提供的分配内存的设备的示意性结构图。
图11是本申请实施例提供的芯片的示意性结构图。
具体实施方式
下面将结合附图,对本申请中的技术方案进行描述。
本申请实施例可以基于虚拟化技术实现。虚拟化技术是一种资源管理技术,是将计算机的各种实体资源,如服务器、网络、内存及存储等,予以抽象、转换后呈现出来,打破实体结构间的不可切割的障碍,使用户可以比原本的组态更好的方式来应用这些资源。
其中,虚拟化技术包括虚拟机和容器。下面,分别对这两种场景分别做一简单介绍。
虚拟机
虚拟机是指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统,是逻辑上的一台计算机。也就是说,虚拟机中有自己想象中的硬件,如处理器、堆栈、寄存器等,还具有相应的指令系统。
虚拟机会将虚拟硬件、内核(即,操作系统)以及用户空间打包在新虚拟机当中,虚拟机能够利用“虚拟机管理程序”运行在物理设备之上。虚拟机依赖于管理程序(hypervisor),通常被安装在系统硬件之上,这导致管理程序在某些方面被认为是一种操作系统。一旦管理程序安装完成,就可以从系统中可用的计算资源当中分配虚拟机实例,每隔虚拟机都能够获得唯一的操作系统和应用程序。简而言之,虚拟机先需要虚拟一个物理环境,然后构建一个完整的操作系统,再搭建一层运行时刻(runtime),然后供应用程序运行。
以虚拟机场景举例,可以在物理机上建立多个彼此独立的虚拟机,每个小的服务在各个虚拟机中运行。具体而言,通过在物理机(称为宿主机)的操作系统(称为宿主操作系统)中安装虚拟机软件并且利用该虚拟机软件进行配置从而在物理机上形成多个虚拟机(称为客户机);根据需要,在每个虚拟机中安装虚拟机的操作系统,通过在虚拟机上的操作系统(称为客户操作系统)运行用户函数或程序以提供相应的服务。多个虚拟机彼此隔离,互不干扰,共同使用物理机的物理资源。
当函数或程序在虚拟机中运行时,占用虚拟机管理的存储空间和诸如端口类的资源。由于虚拟机仅仅在物理机的基础上模拟真实的机器,因此,这些存储空间和资源最终都会指向物理机上的存储空间和资源。
容器
类似于虚拟机,容器也是一个相对独立的运行环境,即,对应用程序及其关联性进行隔离,从而建立一套能够随处运行的空间;在宿主机中建立多个容器,多个容器之间彼此隔离,互补干扰;同时,容器还摆脱了对物理硬件的需求,允许我们可以更加高效地使用计算资源。
但是,容器与虚拟机的主要区别在于虚拟化层的位置和操作系统资源的使用方式。
简单来说,容器不需要安装主机操作系统,可以直接将容器层安装在主机操作系统上,在安装完容器层后,就可以从系统中可用的计算资源中分配容器实例,每个容器化应用都会共享相同的系统操作。这里,容器可以看成是一个装好的一组特定应用的虚拟机,或者说,容器可以认为是虚拟机的一个特例,它直接利用了宿主机的内核,抽象层比虚拟机更少、更加轻量化、启动速度更快。
同时,容器拥有更高的资源使用效率。因为,容器不需要为每个应用分配单独的操作系统,每个容器实例的规模更小、创建和迁移速度更快。这就意味着,相比于虚拟机,单个操作系统能够容纳更多的容器,因此,在相同的硬件设备中,可以部署更多的容器实例。所以,在实际应用中,云提供商非常热衷容器技术。
在本申请实施例中,可以将虚拟机或容器都统称为用于搭载运行环境的运行载体。
基于虚拟化技术,函数服务技术得以很好实现。函数服务是一项基于事件驱动的函数托管计算服务,通过函数服务,用户只需要编写函数代码并设置运行条件,不需要配置和管理服务器等基础设施。其中,每一种函数就是一种服务。
基于虚拟化技术实现的函数服务可以支持多种编程语言的函数的在线编辑和运行,其中,编程语言可以包括:Node JS语言、Python语言、Java语言、Go语言。因此,同一个宿主机中可以运行多个函数,实现运行多个运行载体的场景,其中,该多个函数的语言可以相同也可以不完全相同。
图1是适用于本申请实施例的系统架构的示意图。在图1中,一个宿主机中运行有3个函数,每个函数在一个运行载体中运行。
为了实现占用的内存资源少、函数启动快的性能,提供了一种技术。在该技术中,通过镜像文件将用于描述运行载体(例如,虚拟机或容器)的数据转存至镜像文件中,但是,由于运行函数的运行载体内的进程的内存大小是由用户指定的,因此,在这个过程中,基于进程运行过程中可能占用的内存大小会制作多种镜像文件,任意两种镜像文件中的容器内进程的内存大小都不同。
例如,如图2所示,制作了4种占用的内存大小的镜像文件,不同运行载体内的进程占用的内存的大小是128兆、256兆、512兆和1024兆;根据函数对应的内存大小,即函数在运行过程中占用的内存大小,选择一个内存大小匹配的镜像文件,例如,函数在运行中占用的内存大小为128兆,则选择镜像文件(#1);基于还原后的镜像文件(#1)中的内存大小为128兆的进程的运行载体运行函数。
这里,镜像文件中的数据包括部署运行载体需要的内核态数据和用户态数据。其中,内核态数据包括内核栈、堆、页表、寄存器等。用户态数据包括堆、栈、所有文件、环境变量等。
基于上述描述,可以看出,由于需要基于运行载体内运行的进程占用的多种内存大小制作对应的多种镜像文件,大大降低了内存资源配置的灵活性,例如,若新增加一种内存大小,还需要重新制作一种镜像文件。
此外,基于运行载体内的进程的不同内存大小的镜像文件还原后的运行载体,由于进程的内存大小不同,使得虚拟地址和物理地址之间的映射关系都不同,不同内存大小的进程之间不能共享内存。
为了解决上述问题,本申请实施例基于内存气球制作镜像文件,基于函数占用的内存大小从内存气球中释放与函数需要的内存大小匹配的内存,以满足函数的运行,可以有效地提高运行载体中内存资源配置的灵活性。
图3是本申请实施例提供的分配内存的方法的示意性流程图。以下,结合图3至图8,对本申请实施例的技术方案做一详细描述。
首先,为了便于理解,对本申请实施例中的内存气球做一介绍。
内存气球是针对虚拟化技术提出的概念,内存气球可以让运行载体(例如,虚拟机或容器)在运行过程中动态调整运行载体占用的内存资源。工作原理如下:
内存气球表示的是虚拟化技术中例如虚拟机或容器等运行载体占用的内存,但是,内存气球中的内存是不能直接被运行载体使用的,或者说,内存气球中的内存的实际可用大小为0,即,内存气球不占有物理内存,被操作系统(operating system,OS)统计到的内存大小为0。所以,当宿主机的内存使用紧张时,可以请求运行载体回收利用已分配给运行载体的部分内存,运行载体就会释放其空闲的内存,使得内存气球充气膨胀,从而让宿主机回收内存气球中的内存可用于其他运行载体。反之,当运行载体中的内存不足时,可以让运行载体的内存气球压缩,释放出内存气球中的部分内存,让运行载体使用更多的内存。
综上可以看出,通过使得内存气球压缩或膨胀,可以有效地调整运行载体的内存资源。
下面,对本申请实施例的方法100中的各个步骤进行详细说明。
在步骤S110中,生成用于描述运行载体的镜像文件,该运行载体为用于搭载运行环境的虚拟机或容器。
其中,该镜像文件包括描述该运行载体的数据,包括部署运行载体需要的内核态数据和用户态数据。其中,内核态数据包括内核栈、堆、页表、寄存器等。用户态数据包括堆、栈、所有文件、环境变量等。
同时,在生成镜像文件的过程中,可以配置供该运行载体使用的内存气球,即,通过内存气球为该运行载体预留内存,具体是为该运行载体的进程预留内存。
其中,系统为该运行载体分配的内存气球的内存大小是该运行载体的进程在运行过程中可能占用的最大内存,可选地,该内存气球的内存大小为1.5G;虽然为该运行载体预留了内存,但是,由于内存是填充在内存气球中,内存气球中的内存并不能直接被与运行载体使用,实际可用空间接近为0,即,内存气球不占有物理内存,被OS统计到的内存大小为0。
具体实现中,可以为该运行载体配置多个内存气球,例如,M个内存气球,该M个内存气球的内存大小可以相同,也可以不同,本申请实施例不做任何限定。
可选地,该M个内存气球中的至少两个内存气球的内存大小都相同。
也就是说,该M个内存气球中的至少部分数量的内存气球的内存大小相同,这样,实现起来方便容易。当然,该M个内存气球的内存大小可以都相同。
这里,一个内存气球的内存可以理解为能够释放内存的最小单位,M个内存气球可以释放的内存的内存大小可以理解为进程可能占用的最大内存。
可选地,一个内存气球的内存大小为2k。
可选地,k的取值范围为[6,10]。
可选地,一个内存气球的内存的大小为128兆。
在虚拟化技术中,可以基于各种不同语言编译函数,例如,Java语言、Python语言、Node JS语言和Go语言等。以Java语言为例,我们将运行Java语言编译的函数(称为Java函数)的载体称为Java虚拟机(Java virtual machine,JVM)。
需要强调的是,这里的JVM与上文所述的虚拟机存在区别:JVM可以认为是运行在具有OS的运行载体中的进程,例如,JVM可以认为是运行在容器中的进程;上文所述的虚拟机是具有OS的运行载体,是OS层面的运行载体。
在JVM中,JVM具有垃圾回收(garbage collection,GC)机制,即,存在自动内存管理和卡机清扫机制,概括地说,该机制对JVM中的内存进行标记,并确定哪些内存需要回收,根据一定的回收策略,自动的回收内存,永不停息地保证JVM中的内存空间,防止出现内存泄露和溢出问题。
下面,针对JVM中的内存分配机制做一介绍说明。
JVM中的内存区域包括程序计数器、虚拟机栈、本地方法栈,堆内存、方法区和运行时常量池,其中,堆内存是这几个内存区域中最大的一块。在本申请实施例中,我们仅对与本申请实施例相关的堆内存做介绍。
堆内存被所有线程共享的一块内存区域,所有对象和数组都在堆上进行内存分配。由于堆内存是被线程共享的,线程创建的对象不能一直存放在堆内存中,因此,在一定条件下,JVM会触发GC机制,回收堆内存中没用的对象。
为了进行高效的垃圾回收,虚拟机把堆内存划分成新生代和老生代两块区域。
新生代
对象被创建时,内存的分配首先发生在新生代(大对象可以直接被创建在老生代),大部分的对象在创建后很快就不再使用,因此,会被新生代的GC机制清理掉。
举例说明,新生代可以分为3个区域:伊甸园(Eden)区和两个存活区。大多数刚创建的对象会被分配在Eden区,并且,大多数对象会很快消亡,当Eden区中的内存已经被占满时,执行GC,将消亡的对象清理掉,并将剩余的对象复制到第一个存活区;同理,当第一个存活区的内存被占满后,执行GC,将存活的对象复制到第二个存活区;当两个存活区进行多次切换后,仍然存活的对象就会被复制到老生代。
综上所述,新生代中发生GC的次数比价频繁,对应地,新生代中存放的对象的回收频率也较高。
老生代
相比于新生代,老生代的内存区域相对较大,并且,发生GC的次数也较少,因此,老生代中一般会存放占用空间较大并且回收频率较低的对象。
在JVM中,本申请实施例中的内存气球的内存属于堆内存,进一步地,可以是属于新生代区域的内存,也可以是属于老生代区域的内存。
不过,由于堆内存中的老生代区域中发生GC的次数较少,可以使得从内存气球中释放出的内存不会很快被回收利用,因此,从堆内存中的老生代区域中获取内存气球会更有利于提高方案的可执行性。
在步骤S120中,使用该镜像文件部署该运行载体,包括部署供该运行载体使用的内存气球。
实际上,步骤S120是还原该镜像文件的过程。具体而言,使用操作系统提供的系统调用接口ptrace实现镜像文件中用于描述该运行载体的数据的还原,即,根据镜像文件中用于描述该运行载体的数据部署该运行载体,以便于触发和调度该运行载体的进程的运行。其中,部署该运行载体的过程包括部署供该运行载体使用的内存气球。
在步骤S130中,接收运行函数的请求。
在步骤S120中部署完该运行载体后,开启该运行载体中的进程,开始调用函数。开始阶段,用户输入运行函数的请求,其中,该运行函数的请求可以包括函数的名字等表示函数属性的信息。
这里需要说明的是,在调用该函数之前,设备已经基于用户之前的输入在数据库中存储了与该函数相关的数据,例如,该函数的内容、该函数的名字和该函数的内存大小等数据,以便于后续在调用函数过程中获取与该函数相关的数据。
在步骤S140中,使用该内存气球分配供该函数运行的内存。
具体而言,设备在调用该函数的过程中,基于之前在数据库中存储的与该函数相关的数据,确定运行该函数需要使用的内存大小,基于运行该函数的内存大小,使用该内存气球分配供该函数运行的内存,即,通过压缩该内存气球来释放内存以供该函数的运行。
具体实现中,例如,可以将配置的M个内存气球压缩,以释放至少一个内存气球(记为N1个内存气球),释放的该N1个内存气球的内存就可以被该运行载体的进程使用。例如,假设,该M个内存气球占用的内存总共为1.5G,一个内存气球的内存大小为128兆,则该1.5G的内存气球可以释放1至11个内存气球,对应的内存分别是128兆-1408兆。
图4所示为本申请实施例使用内存气球分配供函数运行的内存的过程的示意图。初始化阶段,从堆空间中生成M个内存气球;随后,在OS层面释放内存,使得OS统计到的实际内存大小为0,所以,该M个内存气球中实际可用的内存为0;最后,基于函数运行过程中需要使用的内存大小,从该M个内存气球中释放N1个内存气球,该N1个内存气球中的内存可以被用于运行该函数。
在步骤S140之后,使用该内存气球分配的内存运行该函数,将函数结果反馈给用户。
下面,结合图5,以容器场景为例,对本申请实施例中调用函数的过程做一详细说明。其中,在容器中的进程可以是JVM。
应理解,图5中的请求派发模块、容器创建模块和函数管理模块都是实现函数调度过程中的功能模块;这3个功能模块也可以集成为一个功能模块,通过一个功能模块完成步骤S211-S234,本申请实施例不做任何限定。
在S211中,请求派发模块接收用户输入的函数调用请求,该函数调用请求用于请求运行函数,该函数调用请求包括函数的名字等信息。
该请求派发模块基于该函数调用请求从数据库中获取与该函数相关的数据,确从该基于之前在数据库中存储的与该函数相关的数据,确定运行该函数需要使用的内存大小。
在S212中,请求派发模块将该函数调用请求发送给容器创建模块。
在S213中,该容器创建模块基于该函数调用请求,为该函数创建容器。
在S221中,请求派发模块向函数管理模块发送第一请求,该第一请求可以是超文本传输协议(hyper text transport protocol,HTTP,)请求,该HTTP请求中包括函数入口、函数实现语言、请求超时、运行函数的CPU的数量以及在S211中确定的函数需要使用的内存大小等信息;
在S222中,函数管理模块基于该第一请求,使用内存气球中分配供容器使用的内存,并且,进行容器的初始化。
在S231中,请求派发模块向函数管理模块发送该函数调用请求。其中,该函数调用请求也是通过HTTP协议发送的。
在S232中,函数管理模块运行函数。
在S233中,函数管理模块将运行函数的结果(即,函数调用结果)反馈给请求探发模块。
在S234中,通过请求派发模块将函数调用结果输出,以反馈给用户。
因此,本申请实施例提供的分配内存的方法,仅需要制作一个用于描述运行载体(例如,虚拟机或容器)的镜像文件,在使用该镜像文件部署该运行载体过程中,通过部署供该运行载体使用的内存气球,使得设备可以基于函数运行需要的内存大小,使用该内存气球动态地分配供该函数运行的内存,以满足该函数的运行,可以有效地提高运行载体中内存资源配置的灵活性。
相比于现有技术制作多个镜像文件的方案,本申请实施例仅需要制作一个镜像文件就可以运行函数,大大节省了磁盘存储空间。
实际函数在运行过程中,随着函数对应的业务量的变化,可能会导致开始为该函数分配的内存不够用或过多,若是不采取相应措施,在内存不够用的情况下,可能会出现内存溢出(out of memory,OOM)现象,在内存过多的情况下,会浪费内存资源。
因此,可选地,该方法还包括:
根据运行该函数的内存大小的变化,使用该内存气球调整为该函数分配的内存。其中,为该函数分配的内存可以理解为该函数在整个运行过程中需要被分配的内存。
即,在运行该函数的过程中,可以根据该函数在实际运行中所需的内存大小,继续使用该内存气球动态地分配内存,以调整为该函数分配的内存,使得调整后的分配给该函数的内存满足该函数的运行需求,或者说,以调整用于运行该函数的运行载体的进程的内存,使得调整后的分配该运行载体的进程的内存满足该函数的运行需求。
在本申请实施例中,有两种调整该函数运行中所需的内存的方式,下面,分别对这两种方式进行说明。
方式1
若当前运行该函数需要的内存大小大于先前运行该函数所需的内大小,则使用该内存气球增加为该函数分配的内存的内存大小。
具体而言,在使用步骤S140中初始分配的内存(为了便于区分与理解,记为第一内存)运行该函数的过程中,会出现运行该函数所需的内存大小逐渐增大的情况,此时,初始分配的第一内存已经不满足该函数的实际运行,或者说,实际运行该函数需要的内存大小大于该第一内存的内存大小,这种情况下,设备可以发出内存不足的警告,那么,基于此,该设备可以使用该内存气球继续为该函数的运行分配内存(为了便于区分与理解,记为第二内存),即,使用该内存气球增加为该函数分配的内存的内存大小,增加的内存大小为该第二内存的内存大小。其中,运行该函数过程中继续分配的第二内存可以基于函数在运行中对应的业务量确定。
具体实现中,从该内存气球释放完该第一内存后剩余的内存中继续压缩该内存气球,以释放该第二内存,从而满足该函数的继续运行。
这里,使用该内存气球为该函数运行过程中继续分配的内存(即,该第二内存)可以是在设备初始为该函数运行分配的该第一内存后一次性分配的内存,也可以是在初始分配该第一内存后多次分配的内存,本申请实施例不限于此。
图6所示为本申请实施例使用内存气球中动态调整为函数分配的内存的过程的示意图。如图6所示,以一个内存气球的内存为128兆为例,通过压缩内存气球,为该函数初始分配128兆的内存,随着函数的继续运行,需要的内存大小增大,128兆的内存已经不满足函数的运行,因此,继续为该函数的运行分配内存,即,继续压缩内存气球来释放内存,将为该函数分配的内存大小扩充至512兆,同理,后续继续为该函数分配内存,将内存的内存大小扩充至1024兆。
具体实现中,同理,以上文所述的初始配置的M个内存气球为例,从剩余的M-N1个内存气球中可以压缩内存气球来释放N2个内存气球的内存。对应地,该N2个内存气球可以是初始释放N1个内存气球后再次释放内存气球的数量,也可以是在初始释放N1内存气球后多次释放内存气球的数量。
方式2
若当前运行该函数需要的内存大小小于先前运行该函数所需的内存大小,则利用该函数使用的内存生成内存气球。
具体而言,在使用步骤S140中初始分配的内存(为了便于区分与理解,记为第一内存)运行该函数的过程中,可能会出现运行该函数所需的内存大小逐渐减小的情况,此时,若是继续使用该第一内存运行该函数,显然比较浪费内存资源,因此,可以触发GC,通过回收该第一内存中的至少部分内存(为了便于区分与理解,记为第三内存)来扩充内存气球中的内存,内存气球充气膨胀,以便于宿主机回收内存气球中的内存用于其他运行载体。
如前所述,为该函数分配的内存气球是多个内存气球,回收内存时会生成至少一个内存气球,也就是说,通过利用该函数使用的内存生成至少一个内存气球来扩充内存气球中的内存。
因此,本申请实施例提供的分配内存的方法,通过基于函数在运行过程需要的内存大小的变化,使用内存气球动态调整为该函数分配的内存,可以使得在当前运行该函数需要的内存大小大于先前运行该函数所需的内大小的情况下避免出现OOM现象,也可以使得在当前运行该函数需要的内存大小小于先前运行该函数所需的内存大小的情况下避免出现内存资源的浪费的现象,都保证了函数的正常运行。这种基于函数运行过程中实际需要的内存使用内存气球继续动态分配内存的方式,可以不用受限于最初静态指定的最大堆限制,即,不需要受限于初次运行函数时指定的内存大小(例如,第一内存的内存大小),同时,也不需要修改源代码。
图7示出了本申请另一实施例的方法300的流程图。方法300描述的是在前运行函数需要的内存大小大于先前运行该函数所需的内大小时,通过使用内存气球增加为该函数分配的内存的内存大小的情况。下面,结合图7,对方法300做一说明。
在S310中,生成用于描述运行载体的镜像文件;
在S320中,使用该镜像文件部署该运行载体,包括部署供该运行载体使用的内存气球;
在S330中,接收用户输入的运行函数的请求;
在S340中,根据该运行函数的请求,使用该内存气球分配供该函数运行的内存;
在S350中,运行该函数。
其中,S310-S340的描述可以参考方法100中针对S110-S140的描述,为了简洁,此处不再赘述。
在函数运行过程中,若运行该函数的实际内存逐渐增大,初始为该函数分配的内存(例如,第一内存)的内存大小已经不满足该函数的运行,则在S360中,继续使用该内存气球,通过压缩该内存气球继续释内存(例如,第二内存),以增加为该函数分配的内存的内存大小,从而满足函数的正常运行。
在本申请实施例中,在生成镜像文件之前,为了使得运行载体中的进程处于稳定状态,可以对函数进行多次训练,当该运行载体中的进程处于稳定状态后,再将用于描述运行载体的所有数据转存至文件系统中生成镜像文件,这样,在还原的镜像文件过程中,可以利用系统写时复制(copy on write,COW)特性,使得还原后的数据减少,例如,以容器中的进程(例如JVM)为例,减少的数据可以包括JVM中的即时编译器(just-in-time compiler,JIT)工作区、Java运行环境(Java runtime)框架运行字节码等数据。
此外,在本申请实施例中,由于仅制作一个内存大小的镜像文件,因此,可以通过启动闲置的Java进程完成内存共享。
具体而言,宿主机中包括多个运行载体,在宿主机上启动一个用于多个运行载体共享内存的闲置Java进程(或者说,JVM),函数调用时,在宿主机上启动Java进程,同一个宿主机上的多个相同内存大小的进程可以共享内存,OS仅会统计到用于共享内存的闲置Java进程中的内存,这样,就实现了多个相同内存大小的进程共享内存的功能。如图8所示,宿主机包括3个运行载体,运行载体(#1)中开启的进程是用于共享内存的闲置进程,运行载体(#2)开启的进程(#A)占用的内存大小和运行载体(#3)开启的进程(#B)中占用的内存大小相同,都是128兆,进程(#A)和进程(#B)在运行过程中共享内存,即,进程(#A)和进程(#B)都在闲置进程中的共享内存中运行函数,OS仅记录闲置进程占用的内存(即,图8中的共享内存),不会记录进程(#A)和进程(#B)占用的内存。
这样,通过启动一个闲置的Java进程完成不同进程间的内存的共享,可以有效地降低内存。
以上,结合图1至图8详细描述了本申请实施例的分配内存的方法,下面,结合图9和图11描述根据本申请实施例的分配内存的装置,方法实施例所描述的技术特征同样适用于以下装置实施例。
图9所示为根据本申请实施例的分配内存的装置的示意性框图。如图9所示,该装置包括处理单元410,该处理单元410用于:
生成用于描述运行载体的镜像文件,该运行载体为用于搭载运行环境的虚拟机或容器;
使用该镜像文件部署该运行载体,包括部署供该运行载体使用的内存气球;
接收运行函数的请求;
根据该运行函数的请求,使用该内存气球分配供该函数运行的内存。
因此,本申请实施例提供的分配内存的装置,仅需要制作一个用于描述运行载体(例如,虚拟机或容器)的镜像文件,在使用该镜像文件部署该运行载体过程中,通过部署供该运行载体使用的内存气球,使得该装置可以基于函数运行需要的内存大小,使用该内存气球动态地分配供该函数运行的内存,以满足该函数的运行,可以有效地提高运行载体中内存资源配置的灵活性。
相比于现有技术制作多个镜像文件的方案,本申请实施例仅需要制作一个镜像文件就可以运行函数,大大节省了磁盘存储空间。
可选地,该处理单元410还用于:
根据运行该函数的内存大小的变化,使用该内存气球调整为该函数分配的内存。
因此,本申请实施例提供的分配内存的装置,通过基于函数在运行过程需要的内存的内存大小的变化,使用内存气球动态调整为该函数分配的内存,可以有效地保证函数的正常运行。
可选地,该根据运行该函数的内存大小的变化,使用该内存气球调整为该函数分配的内存,包括:
若当前运行该函数需要的内存大小大于先前运行该函数所需的内存大小,则使用该内存气球增加为该函数分配的内存的内存大小;或,
若当前运行该函数需要的内存大小小于先前运行该函数所需的内存大小,则利用该函数使用的内存生成内存气球。
可选地,该使用该内存气球分配供该函数运行的内存,包括:
根据该运行函数的请求,确定运行该函数的内存大小;
使用该内存气球分配确定的内存大小的内存。
可选地,该内存气球中的内存属于堆内存中的老年代区域中的内存。
因此,通过堆内存中的老生代区域中获取内存气球,可以有效地减少释放出的内存被回收利用的可能性,便于方案的可执行性。
该装置400可以对应(例如,可以配置于或本身即为)上述方法100、200或300中描述的分配内存的设备(例如,服务器),并且,该装置400中各模块或单元分别用于执行上述方法100、200或300中分配内存的设备所执行的各动作或处理过程,这里,为了避免赘述,省略其详细说明。
在本申请实施例中,该装置400可以为分配内存的设备(例如,服务器),图10示出了根据本申请实施例的分配内存的设备500的示意性结构图。如图10所示,该分配内存的设备500可以包括:处理器510和存储器520,处理器510和存储器520通信连接。该存储器520可以用于存储指令,该处理器510用于执行该存储器520存储的指令。
此种情况下,图9所示的装置400中的处理单元410可以对应图10所示的分配内存的设备500中的处理器510。
在本申请实施例中,该装置400可以为安装在分配内存的设备(例如,服务器)中的芯片(或者说,芯片系统),图11示出了根据本申请实施例的芯片的示意性结构图。该芯片600可以包括:处理器610和存储器620,该处理器610以及存储器620之间通过内部连接通路互相连接。该处理器610用于执行该存储器620中的代码。当该代码被执行时,该处理器610可以实现方法实施例中由分配内存的设备执行的方法100、200或300。为了简洁,这里不再赘述。
此情况下,图9所示的装置400中的处理单元410可以对应图11所示的芯片600中的处理器610。
应注意,本申请实施例上述方法实施例可以应用于处理器中,或者由处理器实现。处理器可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(digital signal processor,DSP)、专用集成电路(application specific integrated circuit,ASIC)、现成可编程门阵列(fieldprogrammable gate array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(read-only memory,ROM)、随机存取存储器(random access memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以所述权利要求的保护范围为准。
Claims (10)
1.一种分配内存的方法,其特征在于,所述方法包括:
生成用于描述运行载体的镜像文件,所述运行载体为用于搭载运行环境的虚拟机或容器,所述镜像文件中配置有供所述运行载体使用的内存气球;
使用所述镜像文件部署所述运行载体,包括部署所述内存气球;
接收运行函数的请求,包括表示函数属性的信息;
根据所述运行函数的请求,使用所述内存气球分配供所述函数运行的内存,且使用所述内存气球分配的内存运行所述函数;
根据运行所述函数的内存大小的变化,使用所述内存气球调整为所述函数分配的内存。
2.根据权利要求1所述的方法,其特征在于,所述根据运行所述函数的内存大小的变化,使用所述内存气球调整为所述函数分配的内存,包括:
若当前运行所述函数需要的内存大小大于先前运行所述函数所需的内存大小,则使用所述内存气球增加为所述函数分配的内存的内存大小;或,
若当前运行所述函数需要的内存大小小于先前运行所述函数所需的内存大小,则利用所述函数使用的内存生成内存气球。
3.根据权利要求1或2所述的方法,其特征在于,所述根据所述运行函数的请求,使用所述内存气球分配供所述函数运行的内存,包括:
根据所述运行函数的请求,确定运行所述函数的内存大小;
使用所述内存气球分配确定的内存大小的内存。
4.根据权利要求1或2所述的方法,其特征在于,所述内存气球中的内存属于堆内存中的老年代区域中的内存。
5.一种分配内存的装置,其特征在于,所述装置包括处理单元,所述处理单元用于:
生成用于描述运行载体的镜像文件,所述运行载体为用于搭载运行环境的虚拟机或容器,所述镜像文件中配置有供所述运行载体使用的内存气球;
使用所述镜像文件部署所述运行载体,包括部署所述内存气球;
接收运行函数的请求,包括表示函数属性的信息;
根据所述运行函数的请求,使用所述内存气球分配供所述函数运行的内存,且使用所述内存气球分配的内存运行所述函数;
根据运行所述函数的内存大小的变化,使用所述内存气球调整为所述函数分配的内存。
6.根据权利要求5所述的装置,其特征在于,所述处理单元具体用于:
若当前运行所述函数需要的内存大小大于先前运行所述函数所需的内存大小,则使用所述内存气球增加为所述函数分配的内存的内存大小;或,
若当前运行所述函数需要的内存大小小于先前运行所述函数所需的内存大小,则利用所述函数使用的内存生成内存气球。
7.根据权利要求5或6所述的装置,其特征在于,所述处理单元具体用于:
根据所述运行函数的请求,确定运行所述函数的内存大小;
使用所述内存气球分配确定的内存大小的内存。
8.根据权利要求5或6所述的装置,其特征在于,所述内存气球中的内存属于堆内存中的老年代区域中的内存。
9.一种分配内存的设备,其特征在于,所述设备包括:
存储器,用于存储指令;
处理器,用于执行所述存储器存储的指令,并且,当所述处理器执行所述存储器存储的指令时,使得所述设备执行如权利要求1至4中任一项所述的方法。
10.一种计算机存储介质,其特征在于,包括计算机指令,当计算机执行所述计算机指令时,所述计算机执行权利要求1至4中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810888058.2A CN109324893B (zh) | 2018-08-07 | 2018-08-07 | 分配内存的方法和装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810888058.2A CN109324893B (zh) | 2018-08-07 | 2018-08-07 | 分配内存的方法和装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109324893A CN109324893A (zh) | 2019-02-12 |
CN109324893B true CN109324893B (zh) | 2021-08-31 |
Family
ID=65264166
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810888058.2A Active CN109324893B (zh) | 2018-08-07 | 2018-08-07 | 分配内存的方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109324893B (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111639018B (zh) * | 2019-03-01 | 2023-05-26 | 阿里巴巴集团控股有限公司 | 一种内存泄漏检测方法和装置 |
US11144356B2 (en) | 2019-10-30 | 2021-10-12 | International Business Machines Corporation | Dynamic determination of memory requirements for function as a service multi-invocation flows |
CN111158860B (zh) * | 2019-12-30 | 2024-02-23 | 咪咕文化科技有限公司 | 数据操作方法、电子设备及存储介质 |
CN112416569B (zh) * | 2020-09-17 | 2022-12-06 | 上海哔哩哔哩科技有限公司 | 缓存内存调整方法、装置及计算机设备 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101986285A (zh) * | 2010-11-03 | 2011-03-16 | 华为技术有限公司 | 虚拟机存储空间管理方法、系统及物理主机 |
CN103430159A (zh) * | 2011-03-13 | 2013-12-04 | 国际商业机器公司 | 虚拟化计算环境中的动态内存管理 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105808319B (zh) * | 2016-03-07 | 2020-01-10 | 华为技术有限公司 | 一种控制内存气球的方法、装置和系统 |
CN107168766B (zh) * | 2016-03-08 | 2020-02-28 | 深信服科技股份有限公司 | 虚拟机内存管理方法和装置、虚拟机管理器 |
-
2018
- 2018-08-07 CN CN201810888058.2A patent/CN109324893B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101986285A (zh) * | 2010-11-03 | 2011-03-16 | 华为技术有限公司 | 虚拟机存储空间管理方法、系统及物理主机 |
CN103430159A (zh) * | 2011-03-13 | 2013-12-04 | 国际商业机器公司 | 虚拟化计算环境中的动态内存管理 |
Also Published As
Publication number | Publication date |
---|---|
CN109324893A (zh) | 2019-02-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109324893B (zh) | 分配内存的方法和装置 | |
JP6370218B2 (ja) | メモリ管理方法、コンピュータシステム、コンピュータプログラム及び記憶媒体 | |
US11630689B2 (en) | Image subunit based guest scheduling | |
JP6138774B2 (ja) | コンピュータにより実行される方法及びコンピュータシステム | |
CN102365625B (zh) | 用于虚拟机的虚拟非一致存储器体系结构 | |
CN102236603B (zh) | 虚拟化环境中垃圾回收的方法和系统 | |
CN108459898B (zh) | 一种资源回收方法及装置 | |
JP5980916B2 (ja) | コンピュータにより実行される方法及びコンピュータシステム | |
US11579908B2 (en) | Containerized workload scheduling | |
US6985976B1 (en) | System, method, and computer program product for memory management for defining class lists and node lists for allocation and deallocation of memory blocks | |
EP4296854A1 (en) | Application management method and apparatus | |
CN105320567A (zh) | 用于有效资源回收的延迟损毁 | |
EP4239474A1 (en) | Serverless container starting method and related device | |
US20230376357A1 (en) | Scaling virtualization resource units of applications | |
JP6859463B2 (ja) | 仮想マシンを起動させるための方法、装置、デバイス及び媒体 | |
CN110447019B (zh) | 存储器分配管理器及由其执行的用于管理存储器分配的方法 | |
US20220318042A1 (en) | Distributed memory block device storage | |
WO2020248512A1 (zh) | 一种构造终端应用行为的运行时模型的方法 | |
CN111435302A (zh) | 一种应用程序的处理方法及装置 | |
CN111435299A (zh) | 一种应用程序的处理方法及装置 | |
CN106547603B (zh) | 减少golang语言系统垃圾回收时间的方法和装置 | |
US20230325179A1 (en) | Just-in-time packager build system | |
WO2023185684A1 (zh) | 一种应用程序的进程查杀方法及电子设备 | |
CN117667306A (zh) | 内存分配方法、装置、处理器系统和计算机可读存储介质 | |
CN114741208A (zh) | 电能表及其内存堆管理方法、内存堆管理装置、存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
TR01 | Transfer of patent right | ||
TR01 | Transfer of patent right |
Effective date of registration: 20220214 Address after: 550025 Huawei cloud data center, jiaoxinggong Road, Qianzhong Avenue, Gui'an New District, Guiyang City, Guizhou Province Patentee after: Huawei Cloud Computing Technology Co.,Ltd. Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd. |