Function-as-a-service container starting acceleration method and device

Abstract

The invention provides a function-as-a-service container starting acceleration method based on snapshot compression-decompression. The method comprises the steps that a basic container instance of a function-as-a-service is started and operated, instance memory access in the whole operation process of the basic container instance is tracked, instance memory access records are obtained, and a priority page of memory access is generated; and when a new container instance is started, loading the memory access priority page to a process memory space of the new container instance, and running the new container instance. According to the method, the memory access conditions of the FaaS container in the initialization stage, the request monitoring stage and the function execution stage are accurately recorded with lower overhead, the container instance is started in advance, it is not needed to wait for all snapshot memory pages to be completely decompressed, part of snapshot decompression delay is covered with instance starting delay and function execution delay, and therefore the decompression efficiency of the FaaS container is improved. Therefore, the total end-to-end time delay is reduced.

Description

Technical Field

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

[0002] In Function as a Service (FaaS), users divide an application into a group of functions and package them into containers and deploy them to the container management platform. After that, users can initiate call requests to this group 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 request.

[0003] Since FaaS often starts and stops a large number of services, reducing the cold start overhead is the core issue for improving the performance of container-based FaaS. The "snapshot-restore" mechanism converts the container initialization overhead into the snapshot recovery overhead, effectively reducing the cold start time of the container. A container snapshot refers to the serialized and saved current execution state of the container process (CPU register values, network connection status, etc.) and memory page data. In order 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 shortcomings: the three processes of snapshot decompression, container startup, and function execution are executed serially, which means that the container cannot be started before the complete memory snapshot is decompressed, resulting in the high-latency snapshot decompression process becoming a bottleneck in the function call process, 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 a function-as-a-service container, comprising: a snapshot generation step, starting and running a basic container instance of the function-as-a-service, tracking instance memory access during the entire running process of the basic container instance, obtaining instance memory access records, and generating a memory access priority page; a snapshot startup step, 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] Furthermore, the priority page includes a first priority page, a second priority page and a third priority page; wherein, the first priority page is generated by recording the instance memory access of the basic container instance in the startup phase; the second priority page is generated by recording the instance memory access of the basic container instance in the function execution phase; the third priority page is generated by the memory that is not accessed in the running phase of the basic container instance; then the function-as-a-service container startup acceleration method also includes: a snapshot storage step, losslessly compressing the second priority page and the third priority page, and storing the compressed second priority page and the third priority page, as well as the first priority page.

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

[0007] Furthermore, the page fault retrieval step includes: when the page fault generated when the function of the new container instance is executed is in a second priority page, the request page corresponding to the page fault in 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 when the function of the new container instance is executed is in the third priority page, the request page corresponding to the page fault in the third priority page is loaded 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, used to generate a priority page for memory access of a basic container instance; starting and running a basic container instance of the function-as-a-service, tracking instance memory access during the entire running process of the basic container instance, obtaining instance memory access records, and generating the priority page; a snapshot startup module, used to load the memory access priority page into the process memory space of the new container instance when starting a new container instance, and then run the new container instance.

[0009] Furthermore, the priority page generated by the snapshot generation module includes: a first priority page, a second priority page and a third priority page; wherein, the first priority page is generated by recording the instance memory access of the basic container instance in the startup phase; the second priority page is generated by recording the instance memory access of the basic container instance in the function execution phase; the third priority page is generated by recording the memory that has not been accessed in the running phase of the basic container instance; then the function-as-a-service container startup acceleration device also includes: a snapshot storage module, which is used to losslessly compress the second priority page and the third priority page, and store the compressed second priority page and the third priority page, as well as the first priority page.

[0010] Furthermore, the snapshot startup module specifically includes: a startup loading module, which is used to load the first priority page into the process memory space when starting the new container instance; a decompression cache module, which is used to decompress the compressed second priority page and the third priority page, and save them to the buffer respectively; a page fault calling module, which is used to monitor the page faults generated when the function of the new container instance is executed when running the new container instance, and according to the page fault situation, call the second priority page or the third priority page from the buffer and load it into the process memory space.

[0011] Furthermore, the page fault calling module includes: when the page fault generated when the function of the new container instance is executed is in a second priority page, the request page corresponding to the page fault in 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 when the function of the new container instance is executed is in the third priority page, the request page corresponding to the page fault in the third priority page is loaded into the process memory space.

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

[0013] The present invention also proposes 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 as described above is implemented.

[0014] In view of the fact that the three processes of snapshot decompression, container startup, and function execution in the existing technical solutions are executed serially, and the high-latency snapshot decompression process seriously increases the end-to-end problem of function calls, the present invention utilizes the staged characteristics of the memory access behavior of the FaaS container and adopts a priority-based memory snapshot page loading method to achieve early startup of the container instance and parallel execution of the snapshot decompression process and the function execution process. The snapshot decompression delay overlaps with the container startup and function execution delays, thereby reducing the end-to-end delay of the function call. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

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

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

[0022] Figure 8 , 9 It is a schematic diagram of the experimental effect of the present invention.

[0023] Wherein, the accompanying drawings are marked as follows:

[0024] 100: Electronic devices 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: Missing page call module

[0028] S1, S2, S3, S4, S5, S6, S7: Steps DETAILED DESCRIPTION

[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] The specific technical problems that need to be solved are: (1) How to record the memory access status of container instances at different stages with low overhead; (2) A snapshot compression method suitable for quick container startup needs to be proposed; (3) A page loading method suitable for quick container startup needs to be proposed.

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

[0045] After the FaaS container instance is started, it will go through the initialization stage, the request listening stage, and the function execution stage. Accurately recording the memory pages accessed in these stages is the basis for subsequent targeted processing of different pages. The existing technology records the memory access address through the page fault event, which causes the recording operation to greatly increase 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 situation at different stages with less overhead. The pages of the first priority are accessed in the instance listening request stage, the pages of the second priority are accessed in the function execution stage, and the pages of the third priority are never accessed again after initialization. The method for recording memory access in the request listening stage is as follows: after the instance enters the request listening stage, the Idle flag of all memory pages of the corresponding process is set. Specifically, the bits of all memory pages of the corresponding process in the / sys / kernel / mm / page_idle / bitmap file are set to "1". If the process memory page is accessed, the corresponding bit will be reset to "0" by the operating system. After that, the / sys / kernel / mm / page_idle / bitmap file is re-read. If the bit of the corresponding container process memory page is "0", the address of the memory page is recorded, and all the accessed memory page addresses are saved as the trace_listening file. This is the first priority page. The method for recording memory access during the function execution phase is similar: set the bits 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 is executed, re-read the / sys / kernel / mm / page_idle / bitmap file. If the bit of the corresponding container process memory page is "0", record the address of the memory page and save all accessed memory page addresses as the trace_invoking file. This is the second priority page.

[0046] (2) Priority-based container snapshot hierarchical compression method

[0047] Since pages of different priorities are randomly distributed in the memory snapshot file, directly compressing the snapshot file cannot guarantee that the high-priority pages can be loaded in advance when decompressing and starting the container. Therefore, the present invention proposes that when compressing the snapshot, the pages of the first, second, and third priorities are first saved as separate 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 take up too much extra storage space), and the pages of the second and third priorities are losslessly compressed respectively.

[0048] (3) Dynamic on-demand loading method for container process memory snapshot pages

[0049] Before starting the container instance and during the execution of the function, the memory page needs to be loaded from the snapshot. The existing work loads all memory pages at once from a complete snapshot that has not been compressed or has been decompressed, or loads them page by page through page faults. The present invention loads memory pages according to different priorities from the snapshot file that is being decompressed. The specific loading method is: when a new request arrives, start to decompress the second and third priority page snapshots in parallel, load the first priority page in parallel and start the container instance, and register the memory area of ​​the container process to a user state page fault file descriptor (User Fault File Descriptor, UFFD), and start a user state page fault processing process (UserPageFaulthandler, UPF handler) to monitor the upcoming page fault; when the function enters the execution stage, a page fault will be generated when the process accesses the unloaded memory area. Since the corresponding memory area has been registered with UFFD, the page fault request generated by the process will be sent to the UPF handler through UFFD for processing. The UPF handler handles the page fault request as follows: if the page fault is caused by accessing the second-priority memory page, the requested page and all the second-priority memory pages that have been decompressed but not yet filled into the process memory since the last page fault are loaded into the process memory space; if the page fault is caused by accessing the third-priority memory page, the requested pages are loaded individually.

[0050] Figure 1 is a flow chart of the method for accelerating the startup of a function-as-a-service container based on snapshot compression-decompression of the present invention, Figure 2 This is a schematic diagram of the snapshot generation-snapshot compression-snapshot decompression-instance startup-page loading process of the present invention. Figure 1 , 2 As shown, in the first embodiment of the present invention, a method for accelerating the startup of a function-as-a-service container based on snapshot compression-decompression is proposed, comprising:

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

[0052] Step S2: After the basic container instance is initialized and enters the request listening state, the instance memory access is tracked to generate a tracking record of the first priority page.

[0053] Step S3, calling the basic container instance, tracking the instance memory access from before the basic container instance executes the function to the completion of the execution, and generating a tracking record of the second priority page; generating a tracking record of the third priority page with the memory page that has never been accessed after the basic container instance is initialized.

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

[0055] Step S5: Perform hierarchical lossless compression on the memory snapshot of the basic container instance. Since pages of 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, when compressing the snapshot, the pages of the first, second, and third priorities are first saved as separate 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 take up too much extra storage space), and the pages of the second and third priorities are losslessly compressed respectively. The pages of the first, second, and third priorities may also be compressed or not compressed, and the present invention is not limited to this.

[0056] Step S6, the system monitors function call requests. If a new request arrives: start lossless decompression of the second and third priority pages in parallel, and output the decompression results to the buffer in sequence; start a new instance, load the first priority page into the instance memory space at one time, and start the user-mode page fault handler (UPF handler) to monitor the page faults generated when the function is executed.

[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 in the following way: if the current page fault is caused by accessing the second-priority memory page, the requested page and all the second-priority memory pages that have been decompressed but not yet filled into the process memory since the last page fault are loaded into the process memory space; if the current page fault is caused by accessing the third-priority memory page, the requested pages are loaded individually.

[0058] It should be noted that, in various embodiments of the present invention, the sequence numbers of the above steps do not mean the order of execution. The order of execution of the steps should be determined by their functions and internal logic, and should not constitute 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 conjunction with the above embodiment. The relevant technical details mentioned in the above embodiment are still valid in this embodiment. In order to reduce repetition, they are not repeated here. Accordingly, the relevant technical details mentioned in this embodiment can also be applied in the above embodiment.

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

[0061] Figure 4 Schematic diagram of the function-as-a-service container startup acceleration device based on snapshot compression-decompression of the present invention. Figure 4 As 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, comprising:

[0062] The snapshot generation module 11 is used to generate a priority page for 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 of the basic container instance during the whole operation process, obtain the instance memory access record, and generate the priority page; wherein, after the basic container instance is initialized and enters the request listening state, the instance memory access is tracked to generate a tracking record of the first priority page; the basic container instance is called, and the instance memory access is tracked from before the basic container instance executes the function to the completion of the execution, and the tracking record of the second priority page is generated; the tracking record of the third priority page is generated with the memory page that has never been accessed after the basic container instance is initialized.

[0063] The snapshot generation module 12 is used to losslessly compress the second priority page and the third priority page, and store the compressed second priority page and the third priority page, as well as the first priority page.

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

[0065] A startup loading module 131, configured to load the first priority page into the process memory space when starting the new container instance;

[0066] A decompression cache module 132, used for decompressing the compressed second priority page and the third priority page, and saving them to a buffer respectively;

[0067] The page fault calling module 133 is used to monitor the page faults generated when the function of the new container instance is executed when the new container instance is running, and according to the page fault situation, call the second priority page or the third priority page from the buffer and load it into the process memory space. When the page fault generated when the function of the new container instance is executed is in a second priority page, the request page corresponding to the page fault in 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 when the function of the new container instance is executed is in the third priority page, the request page corresponding to the page fault in 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. The function-as-a-service container startup acceleration device based on snapshot compression-decompression of the present invention, if its function is implemented in the form of a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a computer-readable storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment 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 of a function-as-a-service container startup acceleration method based on snapshot compression-decompression. It should be understood that the computer-readable storage medium in the embodiment 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 ROM (PROM), an erasable PROM (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 connection dynamic random access memory (SLDRAM) and direct memory bus random access memory (DR RAM).

[0069] Figure 6 Schematic diagram of an electronic device of the present invention. Figure 6As shown, in the fourth embodiment of the present invention, an electronic device 100 is proposed, including a function-as-a-service container startup acceleration device based on snapshot compression-decompression as described above. A person of ordinary skill in the art can understand that all or part of the steps in the above method can be completed by instructing related hardware (such as a processor, FPGA, ASIC, etc.) through a program. All or part of the steps of the above embodiment can also be implemented using one or more integrated circuits. Accordingly, each module in the above embodiment can be implemented in the form of hardware, such as implementing its corresponding functions through an integrated circuit, or in the form of a software functional module, such as implementing its corresponding functions through a processor executing a program / instruction stored in a memory. The embodiments of the present invention are not limited to any particular 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, and the actual knowledge structure recognition device may include more or fewer components than shown in the drawings, or a combination of certain components, or a different arrangement of components.

[0071] The electronic device of the present invention may be any device with data processing capability, and the device with data processing capability may be a device or apparatus such as a computer. The device embodiment may be implemented by software, or by hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, the processor of any device with data processing capability reads the corresponding computer program instructions in the non-volatile memory into the memory and runs the instructions. Figure 7 This is a schematic diagram of the hardware structure of an electronic device of the present invention. Figure 7 As shown, from the hardware level, it is a hardware structure diagram of any device with data processing capability where the function-as-a-service container startup acceleration device based on snapshot compression-decompression of the present invention is located, except Figure 7 In addition to the processor, memory, network interface, and non-volatile memory shown, any device with data processing capabilities in which the apparatus in the embodiments is located may also include other hardware, generally based on the actual functions of the device with data processing capabilities, which will not be described in detail.

[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 process or function described in the embodiment of the present invention is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media sets. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium. The semiconductor medium may be a solid-state hard disk.

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

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

[0075] Application Name describe Memory usage chameleon Rendering HTML Table 27.6MB helloworld Print helloworld 25.3MB image_proc Rotate the input image 90° 29.3MB json_serdes JSON file serialization or deserialization 28.5MB pyaes AES block encryption of text 25.6MB cnn_serve Image Classification 189.8MB video_proc Grayscale the input video 62.6MB lr_train Training a Logistic Regression Model 99.0MB lr_serve Calling the logistic regression model 133.6MB springboot Springboot's helloworld example 309.1MB

[0076] Table 1

[0077] Figure 8 This demonstrates the acceleration effect of the present invention on container snapshot startup. The startup delay is the delay from the start of the snapshot decompression operation after the request arrives to the start of the container instance listening to the request. In the work of snapshot decompression and container startup being executed in series, the startup delay = snapshot decompression delay + instance startup delay. The present invention can reduce the startup delay to 9% to 34% (21% on average) of the original.

[0078] Fig. 9 This demonstrates the effect of the present invention in reducing the end-to-end latency of function calls. End-to-end latency refers to the latency from when an instance receives a user request to when a function is executed, which directly reflects the service quality and affects the user experience. 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% to 95% (53% on average) of the original latency.

[0079] The above implementation modes are only used to illustrate the present invention, but not to limit the present invention. Ordinary technicians in the relevant technical field can 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 should be defined by the claims.

Claims

1. A method for accelerating the startup of a function-as-a-service container, characterized in that: include: The snapshot generation step starts and runs the basic container instance of the function as a service, tracks the instance memory access during the entire operation of the basic container instance, obtains the instance memory access record, and generates a memory access priority page; In the snapshot startup step, when a new container instance is started, the memory access priority page is loaded into the process memory space of the new container instance, and then the new container instance is run.

2. The method for accelerating the startup of a function-as-a-service container according to claim 1, characterized in that: The priority page includes a first priority page, a second priority page and a third priority page; wherein the first priority page is generated by recording the instance memory access of the basic container instance in the startup phase; the second priority page is generated by recording the instance memory access of the basic container instance in the function execution phase; and the third priority page is generated by recording the memory of the basic container instance that is not accessed in the running phase; Then the function-as-a-service container startup acceleration method also includes: The snapshot storage step is to losslessly compress the second priority page and the third priority page, and store the compressed second priority page and the third priority page, as well as the first priority page.

3. The method for accelerating the startup of a function-as-a-service container according to claim 2, characterized in that: The snapshot startup steps specifically include: A startup loading step is performed to load the first priority page into the process memory space when the new container instance is started; A decompression and caching step, decompressing the compressed second priority page and the third priority page, and saving them to a buffer respectively; The page fault retrieval step includes monitoring page faults generated when the function of the new container instance is executed when the new container instance is run, and according to the page fault situation, retrieving the second priority page or the third priority page from the buffer and loading it into the process memory space.

4. The method for accelerating the startup of a function-as-a-service container according to claim 3, characterized in that: The page fault retrieval steps include: When a page fault generated during the execution of a function of the new container instance is within a second-priority page, a request page corresponding to the page fault within the second-priority page and all second-priority pages that have been decompressed and not loaded into the process memory space are loaded into the process memory space; When a page fault generated during the execution of a function of the new container instance is within the third priority page, a request page corresponding to the page fault in the third priority page is loaded into the process memory space.

5. A function-as-a-service container startup acceleration device, characterized in that: include: A snapshot generation module is used to generate a priority page for memory access by the basic container instance; Start and run the basic container instance of the function as a service, track the instance memory access during the entire operation of the basic container instance, obtain the instance memory access record, and generate the priority page; The snapshot startup module is used to load the memory access priority page into the process memory space of the new container instance when starting the new container instance, and then run the new container instance.

6. The function-as-a-service container startup acceleration device according to claim 5, characterized in that: The priority page generated by the snapshot generation module includes: a first priority page, a second priority page and a third priority page; wherein the first priority page is generated by recording the instance memory access of the basic container instance in the startup phase; the second priority page is generated by recording the instance memory access of the basic container instance in the function execution phase; and the third priority page is generated by recording the memory of the basic container instance that is not accessed in the running phase; Then the function, namely the service container startup acceleration device, also includes: The snapshot storage module is used to losslessly compress the second priority page and the third priority page, and store the compressed second priority page and the third priority page, as well as the first priority page.

7. The function-as-a-service container startup acceleration device according to claim 6, characterized in that: 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, used for decompressing the compressed second priority page and the third priority page, and saving them to a buffer respectively; The page fault calling module is used to monitor the page faults generated when the function of the new container instance is executed when the new container instance is running, and according to the page fault situation, call the second priority page or the third priority page from the buffer and load it into the process memory space.

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

9. An electronic device, comprising the function-as-a-service container startup acceleration device as described in 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-as-a-service container startup acceleration method as described in any one of claims 1 to 4 is implemented.

Images