Function-based service container startup acceleration method and device

Abstract

The present invention proposes a method for accelerating the startup of function-as-a-service containers based on snapshot compression and decompression, including: starting and running a basic container instance of function-as-a-service, tracking the instance memory access during the entire running process of the basic container instance, obtaining the instance memory access record, and generating a priority page for memory access; when starting a new container instance, loading the memory access priority page into the process memory space of the new container instance and then running the new container instance. The present invention accurately records the memory access conditions of FaaS containers in the initialization stage, request listening stage, and function execution stage with less overhead, and realizes the early startup of container instances without waiting for all snapshot memory pages to be decompressed, and uses the instance startup delay and function execution delay to mask part of the snapshot decompression delay, thereby reducing the total end-to-end delay.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing. Specifically, the present invention relates to a method and device for accelerating the startup of function-as-a-service containers based on snapshot compression and decompression. Background Art

[0002] In Function as a Service (FaaS), a user slices an application into a set of functions, packages them into containers, and deploys them to a container management platform. Thereafter, the user can initiate a call request for this set of functions according to the application logic. After receiving the user's call request, the platform starts the corresponding function container and executes the function to process the user's request.

[0003] Since FaaS often starts and stops a large number of services, reducing the cold start overhead is the core issue in improving the performance of container-based FaaS. The "snapshot - recovery" mechanism converts the container initialization overhead into snapshot recovery overhead, effectively reducing the cold start time of the container. A container snapshot refers to the current execution state (values of CPU registers, network connection status, etc.) of the container process and the memory page data serialized and saved. To reduce the cache overhead of the snapshot, existing work compresses the memory snapshot. When a function call request arrives, the snapshot is first decompressed, and then the container instance is started. However, the existing work has the following deficiencies: the three processes of snapshot decompression, container startup, and function execution are executed serially, which means that the container cannot be started until the complete memory snapshot decompression is completed, resulting in the high-latency snapshot decompression process becoming the bottleneck of the function call process and seriously increasing the end-to-end latency of the function call. Summary of the Invention

[0004] In view of the above problems, the present invention proposes a method for accelerating the startup of function-as-a-service containers, including: a snapshot generation step of starting and running a basic container instance of function as a service, tracking the instance memory access during the entire running process of the basic container instance, obtaining the instance memory access record, and generating a priority page for memory access; a snapshot startup step of, when starting a new container instance, loading the memory access priority page into the process memory space of the new container instance and then running the new container instance.

[0005] Further, the priority page includes a first priority page, a second priority page, and a third priority page; wherein, the instance memory access record of the basic container instance in the startup phase is used to generate the first priority page; the instance memory access record of the basic container instance in the function execution phase is used to generate the second priority page; the memory that is not accessed by the basic container instance in the running phase is used to generate the third priority page; then the function, i.e., the service container startup acceleration method, further includes: a snapshot storage step of performing lossless compression on the second priority page and the third priority page, and storing the compressed second priority page, the third priority page, and the first priority page.

[0006] Further, the snapshot startup step specifically includes: a startup loading step of loading the first priority page into the process memory space when starting the new container instance; a decompression cache step of decompressing the compressed second priority page and third priority page and respectively saving them to the buffer; a page fault fetching step of listening for page faults generated during the function execution of the new container instance when running the new container instance, and fetching the second priority page or the third priority page from the buffer and loading it into the process memory space according to the page fault situation.

[0007] Further, the page fault fetching step includes: when the page fault generated during the function execution of the new container instance is within a certain second priority page, loading the requested page corresponding to the page fault within the second priority page, and all the decompressed second priority pages that have not been loaded into the process memory space, into the process memory space; when the page fault generated during the function execution of the new container instance is within the third priority page, loading the requested page corresponding to the page fault within the third priority page into the process memory space.

[0008] The present invention also proposes a function as a service container startup acceleration device, including: a snapshot generation module for generating priority pages for the basic container instance to perform memory access; starting and running the basic container instance of the function as a service, tracking the instance memory access throughout the running process of the basic container instance, obtaining the instance memory access record, and generating the priority pages; a snapshot startup module for loading the memory access priority pages into the process memory space of the new container instance when starting the new container instance, and then running the new container instance.

[0009] Further, the priority pages generated by the snapshot generation module include: a first priority page, a second priority page, and a third priority page; wherein, the instance memory access record of the base container instance during the startup phase is used to generate the first priority page; the instance memory access record of the base container instance during the function execution phase is used to generate the second priority page; the memory that is not accessed by the base container instance during the running phase is used to generate the third priority page; then the function, i.e., the service container startup acceleration device, further includes: a snapshot storage module, configured to perform lossless compression on the second priority page and the third priority page, and store the compressed second priority page and third priority page, as well as the first priority page.

[0010] Further, the snapshot startup module specifically includes: a startup loading module, configured to load the first priority page into the process memory space when starting the new container instance; a decompression cache module, configured to decompress the compressed second priority page and third priority page, and save them to the buffer respectively; a page fault fetching module, configured to listen for page faults generated during the function execution of the new container instance when running the new container instance, and according to the page fault situation, fetch the second priority page or the third priority page from the buffer and load it into the process memory space.

[0011] Further, the page fault fetching module includes: when the page fault generated during the function execution of the new container instance is within a certain second priority page, load the requested page corresponding to the page fault within the second priority page, and all the second priority pages that have been decompressed and not loaded into the process memory space, into the process memory space; when the page fault generated during the function execution of the new container instance is within the third priority page, load the requested page corresponding to the page fault within the third priority page, into the process memory space.

[0012] The present invention also provides an electronic device, including the function as a service container startup acceleration device described above.

[0013] The present invention also provides a computer-readable storage medium, storing computer-executable instructions, characterized in that when the computer-executable instructions are executed, the function as a service container startup acceleration method described above is implemented.

[0014] In the existing technical solutions, the three processes of snapshot decompression, container startup, and function execution are executed serially. The high-latency snapshot decompression process seriously increases the end-to-end problem of function calls. The present invention utilizes the phased characteristics of the memory access behavior of FaaS containers and adopts a memory snapshot page loading method based on priority to achieve the parallel execution of the early startup of container instances and the snapshot decompression process and the function execution process. The snapshot decompression delay overlaps with the container startup and function execution delays, reducing the end-to-end delay of function calls. Description of the Drawings

[0015] Figure 1 is a flowchart of the method for accelerating the startup of a function-as-a-service container based on snapshot compression-decompression according to the present invention.

[0016] Figure 2 is a schematic diagram of the snapshot generation-snapshot compression-snapshot decompression-instance startup-page loading process according to the present invention.

[0017] Figure 3 is a system architecture diagram of the function-as-a-service container startup acceleration based on snapshot compression-decompression according to the present invention.

[0018] Figure 4 is a schematic diagram of the function-as-a-service container startup acceleration device based on snapshot compression-decompression according to the present invention.

[0019] Figure 5 is a schematic diagram of the snapshot startup module according to the present invention.

[0020] Figure 6 is a schematic diagram of an electronic device according to the present invention.

[0021] Figure 7 is a schematic diagram of the hardware structure of an electronic device according to the present invention.

[0022] Figure 8 、 9 is a schematic diagram of the experimental effect according to the present invention.

[0023] Among them, the reference numerals are:

[0024] 100: Electronic device 10: Function-as-a-service container startup acceleration device

[0025] 11: Snapshot generation module 12: Snapshot generation module

[0026] 13: Snapshot generation module 131: Startup loading module

[0027] 132: Decompression cache module 133: Page fault fetching module

[0028] S1, S2, S3, S4, S5, S6, S7: Steps Detailed Implementation Modes

[0029] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings. It should be understood that the specific implementation method described herein is only used to explain the present invention and is not used to limit the present invention.

[0030] It should be noted that, in this application, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprises" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0031] Without more constraints, an element defined by the phrase "comprising a..." does not exclude the existence of other identical elements in the process, method, article or apparatus comprising the element.

[0032] In view of the problem that the snapshot decompression process becomes the bottleneck of the FaaS container function call process after the introduction of the snapshot (de)compression operation, resulting in a serious increase in the end-to-end delay of the function call, the present invention proposes a FaaS container startup method and system based on snapshot compression-decompression. This method records the memory access of the container instance at different stages before generating a snapshot for the container, and prioritizes the memory pages according to the hot and cold differences. The pages of the first priority are accessed during the instance listening request stage, the pages of the second priority are accessed during the function execution stage, and the pages of the third priority are never accessed after initialization. The method makes differentiated processing for memory pages of different priorities during the snapshot (de)compression, container startup and function execution phases: (1) Pages of the first priority are not compressed during the snapshot compression phase, but are saved as a separate file. When a function call request arrives, these pages are loaded at once and the function instance is started, and snapshot decompression is started in parallel; (2) Pages of the second and third priorities are also saved as separate files, losslessly compressed during the snapshot compression phase, and decompressed and output in parallel during the snapshot decompression phase. When a page fault occurs in the container process during function execution, if the page fault is caused by accessing a page of the second priority, the requested page and the second priority page that has been decompressed so far are loaded in groups; (3) If the page fault is caused by accessing a page of the third priority, the requested page is loaded individually.

[0033] This method can execute the snapshot decompression process in parallel with the container startup and function execution process. The snapshot decompression delay overlaps with the container startup and function execution delay, thereby reducing the end-to-end delay of the function call.

[0034] The key technical points of the present invention include:

[0035] 1. Lightweight container instance memory access status recording method. The present invention utilizes the idle page mark Idle of Linux memory management to accurately record the memory access status of container instances at different stages with less overhead by tracking the location of idle pages. The memory pages accessed in the request listening stage are classified as the first priority, the memory pages accessed in the function execution stage are classified as the second priority, and other memory pages are classified as the third priority. In this way, the memory access status of the FaaS container in the initialization stage, request listening stage, and function execution stage can be accurately recorded with less overhead.

[0036] 2. Priority-based container snapshot hierarchical compression method. First, the pages of three different priorities are saved as separate files, and then the snapshot files of the second and third priority pages are losslessly compressed. This allows the first priority page to be loaded first when the container instance is started, and the second priority page to be loaded in groups during the function execution phase.

[0037] 3. Dynamic on-demand loading method for container process memory snapshot pages. The present invention adopts a priority-based memory page loading method to load memory pages from a snapshot file that is being decompressed. Pages of the first priority are directly loaded at one time, pages of the second priority are loaded in groups on demand through page faults when accessed, and pages of the third priority are loaded individually on demand through page faults when accessed. This enables early startup of container instances without waiting for all snapshot memory pages to be decompressed, and uses instance startup delay and function execution delay to cover up part of the snapshot decompression delay, thereby reducing the overall end-to-end delay.

[0038] The present invention provides a FaaS container startup acceleration method based on snapshot compression-decompression. The method mainly includes the following steps:

[0039] 1. Record the memory pages accessed by the container instance during the initialization phase, request monitoring phase, and function execution phase.

[0040] 2. Generate and compress snapshots of container instances.

[0041] 3. When a new request arrives, start the function instance and decompress the snapshot in parallel.

[0042] 4. Monitor the page faults generated during the function execution phase and load the memory page from the snapshot according to the page fault type.

[0043] Among them, the specific technical problems to be solved are: (1) How to record the memory access of container instances at different stages with low overhead; (2) It is necessary to propose a snapshot compression method suitable for the rapid startup of containers; (3) It is necessary to propose a page loading method suitable for the rapid startup of containers.

[0044] (1) Method for recording memory access of lightweight container instances

[0045] After the FaaS container instance starts, it will go through the initialization stage, request listening stage, and function execution stage. Accurately recording the memory pages accessed in these stages is the basis for subsequent targeted processing of different pages. Existing technologies record memory access addresses through page fault events, which greatly increases the latency of the first function call. The present invention uses the idle page mark Idle of Linux memory management to accurately record the memory access of different stages with less overhead. The pages of the first priority are accessed during the instance listening request stage, the pages of the second priority are accessed during the function execution stage, and the pages of the third priority are never accessed after initialization. The method for recording the memory access during the request listening stage is as follows: After the instance enters the request listening stage, set the Idle flag bits of all memory pages of the corresponding process. Specifically, set the bit positions of all memory pages of the corresponding process in the / sys / kernel / mm / page_idle / bitmap file to "1". If a memory page of the process is accessed, the corresponding bit position will be reset to "0" by the operating system. Then, read the / sys / kernel / mm / page_idle / bitmap file again. If the bit position of the memory page of the corresponding container process is "0", record the address of this memory page, and save the addresses of all accessed memory pages as the trace_listening file, which are the pages of the first priority. The method for recording the memory access during the function execution stage is similar: Set the bit positions of all memory pages of the corresponding process in the / sys / kernel / mm / page_idle / bitmap file to "1", then call the function. After the function execution is completed, read the / sys / kernel / mm / page_idle / bitmap file again. If the bit position of the memory page of the corresponding container process is "0", record the address of this memory page, and save the addresses of all accessed memory pages as the trace_invoking file, which are the pages of the second priority.

[0046] (2) Hierarchical compression method for container snapshots based on priority

[0047] Since pages with different priorities are randomly distributed in the memory snapshot file, directly compressing the snapshot file cannot guarantee that high-priority pages can be loaded in advance when decompressing and starting the container. Therefore, the present invention proposes that when compressing the snapshot, pages with the first, second, and third priorities are first saved separately as individual files. The pages with the first priority are not compressed (this file is usually very small because the pages with the first priority only account for a very small part of all pages, so it will not occupy too much additional storage space), and the pages with the second and third priorities are losslessly compressed respectively.

[0048] (3) Method for dynamically loading memory snapshot pages of container processes on demand

[0049] Before starting a container instance and during the execution of a function, it is necessary to load memory pages from the snapshot. Existing work loads all memory pages at once from an uncompressed or fully decompressed complete snapshot or loads them page by page through page faults. The present invention loads memory pages from a snapshot file being decompressed according to different priorities. The specific loading method is as follows: When a new request arrives, start decompressing the second- and third-priority page snapshots in parallel, load the first-priority pages in parallel and start the container instance at the same time, and register the memory area of the container process to a user-space page fault file descriptor (User Fault File Descriptor, UFFD), and start a user-space page fault handling process (UserPageFaulthandler, UPF handler) to listen for upcoming page faults; when the function enters the execution phase, a page fault will occur when the process accesses an unloaded memory area. Since the corresponding memory area has been registered to the UFFD, the page fault request generated by the process will be sent to the UPF handler for processing through the UFFD. The UPF handler processes the page fault request in the following way: If the current page fault is caused by accessing a second-priority memory page, load the requested page and all the second-priority memory pages that have been decompressed but not filled into the process memory so far since the last page fault handling into the process memory space; if the current page fault is caused by accessing a third-priority memory page, load the requested page individually.

[0050] Figure 1 It is a flowchart of the function-as-a-service container startup acceleration method based on snapshot compression-decompression of the present invention. Figure 2 It is a schematic diagram of the snapshot generation-snapshot compression-snapshot decompression-instance startup-page loading process of the present invention. As Figure 1 、 2 shown, in the first embodiment of the present invention, a function-as-a-service container startup acceleration method based on snapshot compression-decompression is proposed, including:

[0051] Step S1: Start a container instance on the computing node. When a new container instance is run again, the memory access page loading will be based on the memory access situation of this container instance. Therefore, this container instance is hereinafter referred to as the base container instance.

[0052] Step S2: After the base container instance is initialized and enters the request listening state, track the instance memory access and generate a tracking record of the first-priority pages.

[0053] Step S3: Invoke the base container instance. From before the execution of the function of the base container instance to the completion of the execution, track the instance memory access and generate a tracking record of the second-priority pages; generate a tracking record of the third-priority pages for the memory pages that have not been accessed since the initialization of the base container instance.

[0054] Step S4: Generate a memory snapshot and a memory access tracking file for the base container instance.

[0055] Step S5: Perform hierarchical lossless compression on the memory snapshot of the base container instance. Since pages of different priorities are randomly distributed in the memory snapshot file, directly compressing the snapshot file cannot ensure that high-priority pages can be pre-loaded when decompressing and starting the container. Therefore, when compressing the snapshot, the pages of the first, second, and third priorities are first saved separately as individual files. The pages of the first priority are not compressed (this file is usually very small because the pages of the first priority only account for a very small part of all pages, so it will not occupy too much additional storage space). The pages of the second and third priorities are separately losslessly compressed. It is also possible to compress or not compress the pages of the first, second, and third priorities. The present invention is not limited thereto.

[0056] Step S6: The system listens for function call requests. If a new request arrives: start losslessly decompressing the second- and third-priority pages in parallel, and output the decompression results sequentially to the buffer; start a new instance, load the first-priority pages into the instance memory space at once, and start the user-mode page fault handler (UPF handler) to listen for page faults generated during function execution.

[0057] Step S7: The instance starts to execute the function. The page fault event is captured by the UPF handler and the decompression output buffer of the snapshot storage module is read and processed as follows: If this page fault is caused by accessing a second-priority memory page, load the requested page and all the second-priority memory pages that have been decompressed but not filled into the process memory since the last page fault handling into the process memory space; if this page fault is caused by accessing a third-priority memory page, load the requested page individually.

[0058] It should be noted that in various embodiments of the present invention, the magnitudes of the serial numbers of the above steps do not imply the sequence of execution. The execution sequence of each step should be determined by its function and internal logic, and should not impose any limitation on the implementation process of the embodiments of the present invention.

[0059] The following is a system embodiment corresponding to the above method embodiment. This embodiment can be implemented in cooperation with the above embodiment. The relevant technical details mentioned in the above embodiment are still valid in this embodiment. To avoid repetition, they will not be elaborated here. Correspondingly, the relevant technical details mentioned in this embodiment can also be applied to the above embodiment.

[0060] Figure 3 is the system architecture diagram of the function-as-a-service container startup acceleration based on snapshot compression - decompression of the present invention. As Figure 3 shown, this system runs on the FaaS computing node. The system includes three modules: a snapshot generation module, a snapshot storage module, and a snapshot startup module. The snapshot generation module can sense the state of the container instance (initialization, request listening, function execution), track the memory access of the container instance at different stages, and generate a memory snapshot for the container instance (including a memory access tracking file and a memory page data file); the snapshot storage module can hierarchically store and (de)compress the memory page snapshot; the snapshot startup module can restore the container instance with the snapshot file, listen for page fault events generated during the execution of the instance function, and load memory pages for the instance according to the type of the missing page.

[0061] Figure 4 is a schematic diagram of the function-as-a-service container startup acceleration device based on snapshot compression - decompression of the present invention. As Figure 4 shown, in the second embodiment of the present invention, a function-as-a-service container startup acceleration device 10 based on snapshot compression - decompression is proposed, including:

[0062] A snapshot generation module 11, which is used to generate priority pages for the memory access of the basic container instance; start and run the basic container instance of the function as a service, track the instance memory access during the whole process of running the basic container instance, obtain the instance memory access record, and generate the priority pages; among them, after the basic container instance is initialized and enters the request listening state, track the instance memory access, generate a tracking record of the first priority page, call the basic container instance, and from before the basic container instance executes the function to after the execution is completed, track the instance memory access, and generate a tracking record of the second priority page; generate a tracking record of the third priority page for the memory pages that have not been accessed since the initialization of the basic container instance.

[0063] The snapshot generation module 12 is used to perform lossless compression on the second-priority pages and the third-priority pages, and store the compressed second-priority pages, third-priority pages, and first-priority pages.

[0064] The snapshot generation module 13 is used to load the memory access priority pages into the process memory space of the new container instance when starting the new container instance, and then run the new container instance. As Figure 5 shown, the snapshot startup module 13 specifically includes:

[0065] The startup loading module 131 is used to load the first-priority page into the process memory space when starting the new container instance;

[0066] The decompression cache module 132 is used to decompress the compressed second-priority page and the third-priority page, and save them to the buffer respectively;

[0067] The page fault fetching module 133 is used to monitor the page faults generated during the function execution of the new container instance when running the new container instance, and according to the page fault situation, fetch the second-priority page or the third-priority page from the buffer and load it into the process memory space. Among them, when the page fault generated during the function execution of the new container instance is within a certain second-priority page, the requested page corresponding to the page fault within the second-priority page, and all the second-priority pages that have been decompressed and not loaded into the process memory space are loaded into the process memory space; when the page fault generated during the function execution of the new container instance is within the third-priority page, the requested page corresponding to the page fault within the third-priority page is loaded into the process memory space.

[0068] In the third embodiment of the present invention, a computer-readable storage medium is proposed. If the function of the function-as-a-service container startup acceleration device based on snapshot compression and decompression of the present invention is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a computer-readable storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. Therefore, in the third embodiment of the present invention, a computer-readable storage medium is provided for storing a computer program for a function-as-a-service container startup acceleration method based on snapshot compression and decompression. It should be understood that the computer-readable storage medium in the embodiments of the present invention can be a volatile memory and / or a non-volatile memory. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of random access memory (RAM) are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus random access memory (DR RAM).

[0069] Figure 6 is a schematic diagram of an electronic device of the present invention. As Figure 6As shown in the figure, in the fourth embodiment of the present invention, an electronic device 100 is proposed, which includes the function-as-a-service container startup acceleration device based on snapshot compression and decompression as described above. Those of ordinary skill in the art can understand that all or part of the steps in the above method can be completed by a program instructing relevant hardware (such as a processor, FPGA, ASIC, etc.). All or part of the steps of the above embodiments can also be implemented using one or more integrated circuits. Correspondingly, each module in the above embodiments can be implemented in the form of hardware, for example, by an integrated circuit to implement its corresponding function, or can be implemented in the form of a software function module, for example, by a processor executing a program / instruction stored in a memory to implement its corresponding function. The embodiments of the present invention are not limited to any specific form of combination of hardware and software.

[0070] It should be noted that the structure of the electronic device shown in the drawings of the present invention does not constitute a limitation thereto. The actual knowledge structure recognition device may include more or fewer components than shown in the drawings, or combine some components, or have different component arrangements.

[0071] The electronic device of the present invention can be any device with data processing capabilities, and the any device with data processing capabilities can be a device or apparatus such as a computer. The device embodiment can be implemented by software, or by hardware, or by a combination of software and hardware. Taking software implementation as an example, as a logically meaningful device, it is formed by a processor of any device with data processing capabilities reading the corresponding computer program instructions in the non-volatile memory into the memory for operation. Figure 7 It is a schematic diagram of the hardware structure of an electronic device of the present invention. As Figure 7 shown, from the hardware level, it is a hardware structure diagram of any device with data processing capabilities where the function-as-a-service container startup acceleration device based on snapshot compression and decompression of the present invention is located. In addition to Figure 7 the processor, memory, network interface, and non-volatile memory shown, the any device with data processing capabilities where the device in the embodiment is located usually includes other hardware according to the actual functions of the any device with data processing capabilities, which will not be elaborated herein.

[0072] When implemented using software, the above embodiments may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the processes or functions described in the embodiments of the present invention are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wired (such as infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that the computer can access or a data storage device such as a server or data center that contains one or more sets of available media. The available media may be magnetic media (such as floppy disks, hard disks, magnetic tapes), optical media (such as DVDs), or semiconductor media. The semiconductor media may be a solid-state drive.

[0073] The following is the specific experimental situation of the function-as-a-service container startup acceleration method based on snapshot compression and decompression of the present invention:

[0074] On a PC equipped with an Intel i7-9700 CPU @ 3.00GHz, 32GB RAM, and Linux 6.5.0, the startup latency of the container instance and the end-to-end latency of function calls of the applications shown in Table 1 were tested. The FaaS applications involved in the experiment and their memory occupancy after startup are shown in Table 1.

[0075] Application Name Description Memory Occupied chameleon Render HTML Table 27.6MB helloworld Print helloworld 25.3MB image_proc Rotate the input image by 90° 29.3MB json_serdes Serialize or deserialize JSON files 28.5MB pyaes Perform AES block encryption on text 25.6MB cnn_serve Image classification 189.8MB video_proc Perform grayscale processing on the input video 62.6MB lr_train Train a logistic regression model 99.0MB lr_serve Call the logistic regression model 133.6MB springboot helloworld routine of springboot 309.1MB

[0076] Table 1

[0077] Figure 8 It reflects the acceleration effect of the present invention on container snapshot startup. The startup latency is the latency from the start of the snapshot decompression operation after the request arrives to when the container instance starts listening for requests. In the work where snapshot decompression and container startup are executed serially, the startup latency = snapshot decompression latency + instance startup latency. The present invention can reduce the startup latency to 9% - 34% (average 21%) of the original.

[0078] Figure 9 It reflects the reduction effect of the present invention on the end-to-end latency of function calls. The end-to-end latency refers to the latency from when the instance receives a user request to when the function execution is completed, directly reflecting the service quality and affecting the user experience. The end-to-end latency = instance startup latency + function execution latency. The present invention can reduce the end-to-end latency of function calls to 16% - 95% (average 53%) of the original.

[0079] The above embodiments are only used to illustrate the present invention and are not intended to limit the present invention. Those of ordinary skill in the relevant technical field can also make various changes and modifications without departing from the spirit and scope of the present invention. Therefore, all equivalent technical solutions also belong to the scope of the present invention. The patent protection scope of the present invention shall be defined by the claims.

Claims

1. A method for accelerating the startup of a function-as-a-service container, characterized in that, Including: Snapshot generation step: Start and run the basic container instance of the function as a service, trace the instance memory access during the entire process of running the basic container instance, obtain the instance memory access record, and generate a priority page for memory access; this priority page includes a first priority page, a second priority page, and a third priority page; among them, generate the first priority page based on the instance memory access record of the basic container instance during the startup phase; generate the second priority page based on the instance memory access record of the basic container instance during the function execution phase; generate the third priority page for the memory that has not been accessed during the running phase of the basic container instance. Snapshot startup step: When starting a new container instance, after loading the memory access priority page into the process memory space of the new container instance, run the new container instance.

2. The function as a service container startup acceleration method according to claim 1, wherein The method for accelerating the startup of the function as a service container further includes: Snapshot storage step: Perform lossless compression on the second priority page and the third priority page, and store the compressed second priority page, the third priority page, and the first priority page.

3. The function as a service container startup acceleration method according to claim 2, characterized in that, The snapshot startup step specifically includes: Startup loading step: When starting the new container instance, load the first priority page into the process memory space. Decompression cache step: Decompress the compressed second priority page and the third priority page, and save them to the buffer respectively. Page fault fetching step: When running the new container instance, monitor the page faults generated during the function execution of the new container instance, and according to the page fault situation, fetch the second priority page or the third priority page from the buffer and load it into the process memory space.

4. The function-as-a-service container startup acceleration method according to claim 3, characterized in that The page fault fetching step includes: When the page fault generated during the function execution of the new container instance is within a certain second priority page, load the requested page corresponding to the page fault within the second priority page, and all the second priority pages that have been decompressed and not loaded into the process memory space, into the process memory space. When the page fault generated during the function execution of the new container instance is within the third priority page, load the requested page corresponding to the page fault within the third priority page, into the process memory space.

5. A function-as-a-service container startup acceleration device, characterized in that, Including: Snapshot generation module, used to generate a priority page for the basic container instance to access memory. Start and run the basic container instance of the function as a service, trace the instance memory access during the entire process of running the basic container instance, obtain the instance memory access record, and generate this priority page; this priority page includes a first priority page, a second priority page, and a third priority page; among them, generate the first priority page based on the instance memory access record of the basic container instance during the startup phase; generate the second priority page based on the instance memory access record of the basic container instance during the function execution phase; generate the third priority page for the memory that has not been accessed during the running phase of the basic container instance. Snapshot startup module, used to load the memory access priority page into the process memory space of the new container instance and then run the new container instance when starting the new container instance.

6. The function-as-a-service container startup acceleration device according to claim 5, characterized in that The function, i.e., the service container startup acceleration device, further includes: A snapshot storage module, configured to perform lossless compression on the second-priority pages and the third-priority pages, and store the compressed second-priority pages, the third-priority pages, and the first-priority pages.

7. The function as a service container startup acceleration device according to claim 6, wherein, The snapshot startup module specifically includes: A startup loading module, configured to load the first-priority pages into the process memory space when starting the new container instance; An uncompressing cache module, configured to uncompress the compressed second-priority pages and third-priority pages, and save them to the buffer respectively; A page fault fetching module, configured to listen for page faults generated during the function execution of the new container instance when running the new container instance, and according to the page fault situation, fetch the second-priority pages or the third-priority pages from the buffer and load them into the process memory space.

8. The function as a service container startup acceleration device according to claim 7, wherein The page fault fetching module includes: When the page fault generated during the function execution of the new container instance is within a certain second-priority page, load the requested page corresponding to the page fault within the second-priority page, and all the second-priority pages that have been uncompressed and not loaded into the process memory space, into the process memory space; when the page fault generated during the function execution of the new container instance is within the third-priority page, load the requested page corresponding to the page fault within the third-priority page into the process memory space.

9. An electronic device, including the function, i.e., the service container startup acceleration device according to any one of claims 5 to 8.

10. A computer-readable storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, the function, i.e., the service container startup acceleration method according to any one of claims 1 to 4 is implemented.

Images